initialization problem

[Marcelo Pinto]

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

This code is the consequence of lazy Search/Replace (s/msg0/msg/g -
initially the function parameter and the first variable after the _=_
was msg0).
But shouldn't the compiler complain about the initialization of an
object use the same object? What am I missing?

TIA,

Marcelo Pinto

[Neelesh Bodas]

Marcelo Pinto wrote:

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

But shouldn't the compiler complain about the initialization of an

object use the same object? What am I missing?

Which compiler? The above code (after removing all extra portion) gives
redeclaration error with Comeau online (msg has already been declared
in the current scope)

[peter steiner]

Marcelo Pinto wrote:

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

This code is the consequence of lazy Search/Replace (s/msg0/msg/g -
initially the function parameter and the first variable after the _=_
was msg0).
But shouldn't the compiler complain about the initialization of an
object use the same object? What am I missing?

you are allowed to redeclare already visible identifiers in different
scopes. only redefining an identifier that has already been defined in
the same scope is illegal and yields a compiler error.

your for() loop body is a new scope, thus the identifier msg can be
defined again. you have to be aware though that you are effectively
hiding the already visible identifier, which is probably not what you
intended to do.

-- peter

[Victor Bazarov]

Neelesh Bodas wrote:

Marcelo Pinto wrote:

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

But shouldn't the compiler complain about the initialization of an

object use the same object? What am I missing?

Which compiler? The above code (after removing all extra portion) gives
redeclaration error with Comeau online (msg has already been declared
in the current scope)

Really? Did you remove the 'for' as well? It's introduces the proper
scope limitation for the "inner" msg...

V

[peter steiner]

Neelesh Bodas wrote:

Marcelo Pinto wrote:

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

But shouldn't the compiler complain about the initialization of an

object use the same object? What am I missing?

Which compiler? The above code (after removing all extra portion) gives
redeclaration error with Comeau online (msg has already been declared
in the current scope)

you probably removed a little bit too much of the given example... ;-)

-- peter

[Martin Vejnar]

Marcelo Pinto wrote:

void f(const std::string & msg)
{ { std::string msg = msg + " " + another_string; //1 } }
.... But shouldn't the compiler complain about the initialization of an
object use the same object? What am I missing?

The Standard clearly states, that in

int x = 12;
{ int x = x; }

the second _x_ is initialized with its own (indeterminate) value.

But in this particular case I wonder what will happen, since _msg_
should probably be constructed before it is used. My belief is that
_msg_ will be constructed with the default constructor, then the
expression will be evaluated and then the assignment operator will be
called.

Martin.

[Jim Langston]

"Marcelo Pinto" <mp******@gmail .com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
This is legal. This msg local to the for loop hides the msg parameter. So
it basically becomes:
std::string msg = "" + " " + another_string;

which is probably why you're asking.

No, there are generally no compiler warnings for hiding variables. Although
there generally are for hiding methods in classes.
//...
}
//...
}

This code is the consequence of lazy Search/Replace (s/msg0/msg/g -
initially the function parameter and the first variable after the _=_
was msg0).
But shouldn't the compiler complain about the initialization of an
object use the same object? What am I missing?

TIA,

Marcelo Pinto

[Marcelo Pinto]

Neelesh Bodas escreveu:

Which compiler? The above code (after removing all extra portion) gives
redeclaration error with Comeau online (msg has already been declared
in the current scope)

aCC: HP ANSI C++ B3910B A.03.37

[Martin Vejnar]

Neelesh Bodas wrote:

Marcelo Pinto wrote:

void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1
//...
}
//...
}

Which compiler? The above code (after removing all extra portion) gives
redeclaration error with Comeau online (msg has already been declared
in the current scope)

It can hardly be redeclared as long as it is in the inner scope. You
probably removed the "extra" for loop. Don't do that or at least remove
only `for (...)` line.

Martin.

[Greg]

Jim Langston wrote:

"Marcelo Pinto" <mp******@gmail .com> wrote in message
news:11******** *************@g 44g2000cwa.goog legroups.com...

Hi,

Consider the following code snipet:
void f(const std::string & msg)
{
//...
for (...)
{
//...
std::string msg = msg + " " + another_string; //1

This is legal. This msg local to the for loop hides the msg parameter. So
it basically becomes:
std::string msg = "" + " " + another_string;

which is probably why you're asking.

No, there are generally no compiler warnings for hiding variables. Although
there generally are for hiding methods in classes.

The local "msg" variable is accessed before it has been initialized
(because it is used in its own initializer.) Since the value of the msg
variable is indeterminate before its initialization, the outome of this
expression, though legal, is undefined.

Greg