self initialization (??)

[Srini]

Pardon me if this is trivial.

I think I read somewhere that statements like this cause undefined
behavior.

int n = n;

How is the above statement different from

int n(n);

This above statement gives an error saying that 'n' is undeclared. I
saw the assembly listing for this following piece of code. Using g++
3.3.3

int x = 10;
int n = x;
int m(x);

The assembly listing was something like this...

movl $10, -4(%ebp)
movl -4(%ebp), %eax
movl %eax, -8(%ebp)
movl -4(%ebp), %eax
movl %eax, -12(%ebp)

I see that for both of these, the assembly code generated is the same.
May be its different for class objects. This whole thing brings doubts
in my mind whether I must check for self initialization in copy
constructors. Please share your thoughts on this.

Regards,
Srini

[Bob Hairgrove]

On 22 Jun 2005 03:08:34 -0700, "Srini" <sr*********@gmail.com> wrote:

Pardon me if this is trivial.

I think I read somewhere that statements like this cause undefined
behavior.

int n = n;

How is the above statement different from

int n(n);
I think it is a matter of scope. If there is a variable n defined
within the enclosing (outer) scope, the local n will use the outer n
to initialize itself with. Afterwards, the local n hides the outer n.
But I am not 100% sure that this is well-defined behavior.

If there is no n visible in the outer scope, the code is ill-formed.
This above statement gives an error saying that 'n' is undeclared. I
saw the assembly listing for this following piece of code. Using g++
3.3.3

int x = 10;
int n = x;
int m(x);

The assembly listing was something like this...

movl $10, -4(%ebp)
movl -4(%ebp), %eax
movl %eax, -8(%ebp)
movl -4(%ebp), %eax
movl %eax, -12(%ebp)

I see that for both of these, the assembly code generated is the same.
May be its different for class objects. This whole thing brings doubts
in my mind whether I must check for self initialization in copy
constructors. Please share your thoughts on this.

It is not possible. In a copy constructor, you always have a valid
object to construct from because the argument to the copy c'tor is a
const reference. Whether or not that object has been correctly
initialized or not is another story; but there IS an object, otherwise
the compiler couldn't generate a reference to it. And since the object
being constructed doesn't exist yet, there is no need to check.

Are you more concerned with self assignment, perhaps?

--
Bob Hairgrove
No**********@Home.com

[Stephen Howe]

> This whole thing brings doubts

in my mind whether I must check for self initialization in copy
constructors.

No you should not.
Doing either

SomeClass x = x;
SomeClass x(x);

is ill-formed.
If the copy-constructor is invoked here, what would you do inside if you did
detect self intialisation?
Leave it as a zombie object? There is nothing good you can do.

Stephen Howe

[Srini]

> SomeClass x = x;

SomeClass x(x); is ill-formed.
If the copy-constructor is invoked here, what would you do inside if you did
detect self intialisation?
Leave it as a zombie object? There is nothing good you can do.

Mostly this is a compiler issue. Because with aCC, both

int n = n;
int m(m);

went thru fine. There were no problems with int but with string I got a
seg fault. Even if the issue is the compiler, is there nothing in the
standard that allows/disallows both? What I feel is that both of them
must have consistent behavior.

Regards,
Srini

[Jacques Labuschagne]

Srini wrote:

seg fault. Even if the issue is the compiler, is there nothing in the
standard that allows/disallows both? What I feel is that both of them
must have consistent behavior.

Both seem to be disallowed by 8.5/2:
"[variables] of namespace scope can be initialized by arbitrary
expressions involving literals and previously declared variables and
functions."

In
int n = n;
the variable n is neither a literal nor a previously declared variable.

J.

[Ron Natalie]

Jacques Labuschagne wrote:

Srini wrote:

seg fault. Even if the issue is the compiler, is there nothing in the
standard that allows/disallows both? What I feel is that both of them
must have consistent behavior.

Both seem to be disallowed by 8.5/2:
"[variables] of namespace scope can be initialized by arbitrary
expressions involving literals and previously declared variables and
functions."

In
int n = n;
the variable n is neither a literal nor a previously declared variable.

J.

It is a previously declared variable. The first lines of 3.3.1 "Point
of declaration" address this specifically:

The point of declaration for a name is immediately after its complete
declarator (clause 8) and before its
initializer (if any), except as noted below. [Example:
int x = 12;
{ int x = x; }
Here the second x is initialized with its own (indeterminate) value. ]

[Jacques Labuschagne]

Ron Natalie wrote:

It is a previously declared variable. The first lines of 3.3.1 "Point
of declaration" address this specifically:

The point of declaration for a name is immediately after its complete
declarator (clause 8) and before its
initializer (if any), except as noted below. [Example:
int x = 12;
{ int x = x; }
Here the second x is initialized with its own (indeterminate) value. ]

Far out. Thanks.