7

I maybe asking a dumb question, but I looked at the wikipedia page for RVO here and could not stop wondering if that behavior is wrong. I tried it in my machine and RVO is fully kicked in despite optimization level. What if there was actually something BIG happenning in a constructor? I know it shouldn't, but what if? I can't understand why RVO would still happen when there are side effects in the constructor.

EDIT: -fno-elide-constructors seems to stop RVO. But the question remains.

EDIT2: On a more serious note, how many people know about something like this? It maybe in the standard, but it is still a really ugly feature as I see it. At least compilers should disable it by default and provide a switch for people who know about this. :)

EDIT 3: I still insist that this is really bad. :). I don't think I know of any other language constraint like this that goes directly against the syntax of language. Everything else throws either compiler or linker errors right?

nakiya
  • 14,063
  • 21
  • 79
  • 118
  • 1
    Personally, I think that RVO is an abomination. – John Dibling Oct 11 '10 at 14:09
  • 11
    Can you come up with a good use case for having nontrivial side effects in a copy constructor? I don't have one, offhand. They generally are called behind the scenes, and it's real easy to make a mistake when figuring when they will be called. That, to me, is a very good reason to leave the side effects out. – David Thornley Oct 11 '10 at 15:29
  • 1
    I don't have any reason to put side effects inside a copy constructor. :) – nakiya Oct 11 '10 at 15:30
  • 6
    @nakiya: Right. I'm not worried about possible pitfalls in doing something that I already consider a pitfall. On the pro-RVO side, it makes it possible to eliminate some copies, which may be time-consuming and frequently executed, allowing C++ programs to be more efficient (and allowing efficiency was higher on the list of design criteria than preventing misuse). – David Thornley Oct 11 '10 at 15:49
  • Shouldn't it be working right before it is optimized? I am not against RVO, I think the main reason for it is without it all those containers in standard library would be pretty cumbersome. But, you can still provide a keyword or compiler switches, can't you? – nakiya Oct 11 '10 at 16:09
  • 2
    @nakiya: To some extent, yes, although I'd argue that code that relies on side effects in the copy constructors is probably not working right. However, the optimization is one that's really clumsy to put in manually later. One design goal of C++ was to eliminate gratuitous inefficiencies, and having to run a potentially expensive copy constructor unnecessarily is a gratuitous inefficiency. I'm not saying RVO is correct for every language, but it's consistent with the C++ philosophy. – David Thornley Oct 11 '10 at 17:04
  • 1
    @David: I can agree with you that it is very bad practice to have a copy constructor with side effects. No argument on that one. But anyone who has used classes in C++ has at one time or another used a copy constructor. I don't see why such a basic functionality can be so error-prone. I have used C++ for some time now, only now did I bump into this RVO topic. Though it maybe partly due to ignorance on my part, I don't think this is a very 'hot' topic. :D. Peace. – nakiya Oct 11 '10 at 17:20

3 Answers3

20

The standard mandates that operations with concern a program's observable state must not be optimized away, except for copy construction in certain circumstances. You must not rely on copy constructors to be executed, even if they have side effects you expect to see (e.g., console output).

sbi
  • 219,715
  • 46
  • 258
  • 445
  • So this is why passing by value is better? – nakiya Oct 11 '10 at 11:57
  • It's one reason why pass-by-value *might* be better. That's not universal advice either. Sometimes, pass-by-value enables optimizations that wouldn't be possible if passing by reference, but it may also be slower in some cases. :) – jalf Oct 11 '10 at 11:59
  • Further, I thought boost::shared_ptr depended on those same two functions for reference counting. What happens there? – nakiya Oct 11 '10 at 12:00
  • 5
    @nakiya: in the case of `shared_ptr`, creating an extra temporary object that gets destroyed almost immediately has the effect of incrementing then decrementing the reference count, so the reference count ends up the same whether the optimization happens or not. – Doug Oct 11 '10 at 12:02
  • 3
    @nakiya: well, if the copy constructor is optimized away, then it is because the copy is optimized away, and never created at all. And then it's ok that the reference counter isn't incremented (in fact, it's the only correct behavior). ;) – jalf Oct 11 '10 at 12:03
  • The compiler still isn't allowed to just perform a `memcpy` instead of calling the copy constructor. If it copies the object, it has to do so properly, using the copy constructor. But it's allowed to eliminate the copy entirely, and then it can also eliminate the copy constructor call. – jalf Oct 11 '10 at 12:04
  • Seriously, how many C++ developers have read every corner of the standard? I for one certainly have not :(. Isn't it just plain dangerous to leave something like that as the default behavior? I mean, this could cause bugs in programs and people will just waste time. I'm not saying it's common, but I don't like it. Just what I think. – nakiya Oct 11 '10 at 15:29
  • 4
    @nakiya: Return value optimization is found in lots of more advanced C++ books. I would venture to say that programs where copy constructors have side effects are likely to be buggy whether or not RVO is in effect, because I think it's a real bad idea. – David Thornley Oct 11 '10 at 15:45
  • 3
    @nakiya: lots of things in C++ can cause bugs if the developer isn't aware of them. But if you write your copy constructor to be have "sensibly", that is, it constructs a copy, and nothing else, then it *just works* with and without RVO. – jalf Oct 11 '10 at 18:01
13

As said in the other answers, the compiler is allowed optimize away even non trivial copy constructors and assignment operators.

12.8.15

When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies):

— in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function’s return value

— when a temporary class object that has not been bound to a reference (12.2) would be copied to a class object with the same cv-unqualified type, the copy operation can be omitted by constructing the temporary object directly into the target of the omitted copy

DerKuchen
  • 1,840
  • 1
  • 15
  • 15
  • +1 for the quote, please also provide a link to a copy of the standard for verification – Matt Joiner Oct 12 '10 at 04:43
  • 1
    @Matt: That would make it a reference to reference. Scientific Papers and Books usually mention only BibTex or the name of some book, too, without mentioning Amazon or ISO where you can get those titles. Anyways, for your convenience, the latest draft of the standard is freely available at http://open-std.org – Sebastian Mach Sep 29 '11 at 05:33
  • In the modern age of WWW, I'd expect no less than a hyperlink pointing directly to this paragraph. In my defence, the author of this answer doesn't even indicate what standard, year, or version he's lifted this from. – Matt Joiner Sep 29 '11 at 07:07
  • 3
    @MattJoiner, you can expect it all you like but you aint gonna get it. There are no (legal) HTML copies of the standard online, it's a copyrighted document only officially available in paper or PDF form, so it would be difficult and/or naughty to link to a specific paragraph in a convenient form. [Here](https://github.com/cplusplus/draft/blob/d8fb8cf16dd05f711d33b3749a757d69068e45ef/source/special.tex#L2957) is the LaTeX source for that paragraph, shortly before the final standard was published, but it's not terribly convenient reading LaTeX. – Jonathan Wakely Jun 26 '12 at 16:35
  • 1
    `even non trivial copy constructors and assignment operators` zoom: `assignment` Nowhere in this quote does it refer to the copy assignment operator. Do you have an _actual_ citation for that? Spoiler: I don't think you'll find one, because of the answer here: [Why doesn't RVO happen for assignment operator?](http://stackoverflow.com/a/20250126/2757035) i.e., for blatantly obvious reasons, **[N]RVO is not applicable to copy-assignment.** – underscore_d Jul 13 '16 at 09:59
8

Define "wrong". The C++ language explicitly permits this kind of optimization even though it is observable. If the behavior of your program depends on a specific implementation, then unfortunately you are not using ISO C++, but some dialect.

Helmut Grohne
  • 6,578
  • 2
  • 31
  • 67