Does "Return value optimization" cause undefined behavior?

Reading this Wikipedia article pointed by one of the repliers to the following question:

http://stackoverflow.com/questions/2323225/c-copy-constructor-temporaries-and-copy-semantics

I came across this line

Depending on the compiler, and the compiler's settings, the resulting program may display any of the following outputs:

Doesn't this qualify for undefined behavior? I know the article says Depending on the compiler and settings but I just want to clear this.

From stackoverflow

• No. The behaviour is defined to be one of the outputs on the list. Undefined behaviour includes demons flying out of your nose.

  Steve314 : I've seen many programs with undefined behaviour, and not one has caused demons to fly out of my nose. I think your problem may be caused by something else.

• undefined behavior is quite different from implementation defined behavior, which is what's involved here.

  Jerry Coffin : It's not really implementation defined -- that would require the implementation to document what happens, which isn't required in this case.

• No, it's not undefined behavior. Undefined behavior has a specific definition in the standard (mostly: "behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements.") In this case, the behavior is unspecified, but not undefined.

  The difference is that any execution of anything with undefined behavior makes all the behavior of your program undefined (i.e. anything can happen). With this particular unspecified behavior, only one of two things can happen: either the copy constructor executes, or it doesn't.

  Matthieu M. : I remember I was quite confused when I began between: undefined, unspecified and implementation-defined. Very good and concise explanation.

• Depends what you mean by undefined. I believe what others have said here - by the definition the standards document use. But I also know that when someone says "either this or that, I'm not telling you which" I think of it as undefined behaviour.

  It's not a big deal, though, as it should never cause an error. When you define certain methods, you are expected to define them following particular conventions - it's a kind of implicit contract between you, the compiler and the people who will use and maintain your code.

  In this case, whether you get a copy-construct etc or the optimised behaviour, the effect is expected to be the same - the caller receives the wanted value. If your copy constructor is printing "Hello World!" or has other inappropriate side-effects, it isn't implementing the expected behaviour for a constructor, so the fault is yours for breaking the contract.

  legends2k : +1 for saying about the _side effects_ which might go un-executed silently due to this optimization :) If it's a print statement which you're eagerly watching for on the terminal, you can catch it though; while something more silent, say, passing a message to another object when construction happens, will not happen and be hard to catch.

  legends2k : So can I infer from this that, irrespective of the type of constructor (be it default, copy, etc.), I shouldn't be doing anything specific other than initializing the members?

  UncleBens : @legends2k: Yes. The standard allows copy constructor calls to be elided when returning from functions, which means your code shouldn't try to rely on side-effects in copy-constructors.

  Steve314 : Not true. It shouldn't be doing anything other than constructing the object, which is not quite the same thing. For example, the object may own data that lives in some external container - e.g. custom allocation. Is the change to that a side-effect? Strictly yes, but in practice, maybe no. However, it's hard to express the conditions - subjectively it's about separating "what" from "how", but it's OK if the app allows the user to report/configure some of the "how" as part of the "what". Yes - I think that's absolutely definitely maybe kind-of possibly it. In part. Perhaps. Clear?

  legends2k : @Steve314: *Gaga gugu* :)