5

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

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.

Community
  • 1
  • 1
Aaron S
  • 5,023
  • 4
  • 29
  • 30
  • 3
    There's implementation-defined, in which the compiler implementer must document the behavior, then here's unspecified which means the compiler can do whatever it wants as long as the "observable behavior" remains the same. Then there's undefined behavior, which means you've entered a state in the program where it's execution is no longer defined. RVO is a case where observable behavior is allowed to change. – GManNickG Feb 24 '10 at 06:37

4 Answers4

12

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.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • I remember I was quite confused when I began between: undefined, unspecified and implementation-defined. Very good and concise explanation. – Matthieu M. Feb 24 '10 at 08:28
2

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

See: Nasal Demons

janm
  • 17,976
  • 1
  • 43
  • 61
1

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

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • 4
    It's not really implementation defined -- that would require the implementation to document what happens, which isn't required in this case. – Jerry Coffin Feb 24 '10 at 05:50
0

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.

  • +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 Feb 24 '10 at 09:30
  • 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? – legends2k Feb 24 '10 at 09:33
  • @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. – UncleBens Feb 24 '10 at 10:56
  • 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? –  Feb 24 '10 at 11:10