15

The following code is allowed in C++:

int a = a;

or

Type name = name;

Both lead to an uninitialized object being initialized by itself, which often leads to undefined behavior.

Is such code ever needed or reasonable? Are there cases of such code being useful?

Mechanical snail
  • 29,755
  • 14
  • 88
  • 113
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • 1
    I think you need to clarify what you ask about. Do you ask whether it's "valid code" or whether "such code [is] ever needed or reasonable" ? – Johannes Schaub - litb Aug 01 '11 at 18:54
  • This reminds me of @AndrewJacksonZA 's reply to [this question](http://stackoverflow.com/questions/194484/whats-the-strangest-corner-case-youve-seen-in-c-or-net/1800162#1800162) – Rag Aug 09 '11 at 20:52

5 Answers5

21

This reminded me of an old thread of the GCC mailing list in which Gabriel Dos Reis gave the following example to construct a one-node circular list:

struct Node {
  Node* link;
  Node(Node& n) : link(&n) { }
};

int main()
{
  Node x = x;
}
mskfisher
  • 3,291
  • 4
  • 35
  • 48
adl
  • 15,627
  • 6
  • 51
  • 65
17

You are allowed to use the name of the variable in its initializer. The code

Type name = name;

is probably not useful, but the code

Type name = f(&name);

might be.

There are many places where the language syntax doesn't forbid useless constructs. :-)

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
3

Sometimes, if you have complex initializers, then you can have to refer to it. This is used in constructors where you pass pointer or references to this in the initialization list.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Perhaps, but I wonder if the drawbacks are bigger than the benefits when allowing this. – daramarak Aug 01 '11 at 12:08
  • 1
    I don't understand your sentence, "if you have complex initializers, then you can have to refer to it". Who is "it"? Doesn't the OP's construction *always* result in an uninitailized state for PODs? – Kerrek SB Aug 01 '11 at 12:12
  • @daramarak: If you have a complex type, which requires a pointer or reference to your own type in it's constructor, how else could you possibly construct it? – Puppy Aug 01 '11 at 12:30
  • @daramarak: Or, alternatively, you could completely safely just refer to it. – Puppy Aug 01 '11 at 13:36
  • @Kerrek SB, for PODs yes, but the OP also use a complex type. – daramarak Aug 01 '11 at 13:45
  • @daramarak: Well, it allows perfectly safe code, so it's perfectly reasonable to allow it. – Puppy Aug 01 '11 at 13:49
1

It is valid, but it almost goes without saying that

int a = a;

is more harmful than not.

As for other types I would say, that one might do useful work by overloading the copy constructor and using default construction.

On the other hand I cannot think of any circumstance where such code is needed, and since IMO the code gets so convoluted by this syntax, my subjective opinion is that it isn't any good reason to be able to write such assignments. Especially not when one consider all the bugs that could be prevented by disallowing (or at least warn about) the syntax.

daramarak
  • 6,115
  • 1
  • 31
  • 50
0

Such code can never be useful which leads uncertainty.

First case is undefined behavior (initializing with uninitialized self) and 2nd case is also an undefined behavior (copy constructor is called on uninitialized object). It should never be practiced.

iammilind
  • 68,093
  • 33
  • 169
  • 336
  • If you take into consideration DeadMGs answer, it can be useful. Also initializing with an uninitialized object is not UB, but some uses of object might. – daramarak Aug 01 '11 at 13:51