Is the object copied or not when RVO/NRVO kicks in?

Question

I can't get my head around RVO (and NRVO) definition because of multiple questions like this one that to me look assuming that RVO omits a copy constructor. Now according to 12.8.15

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.

Which looks like it's not the copy constructor call is being omitted, but the copy itself - just the object is constructed at the "copy" location in the first place and so there's no "original" object and no copying at all. So even when a class has a private copy constructor it can be returned from a function when RVO kicks in because there's no copy.

Do I get it right? Is the copying itself omitted or is the copy constructor invokation omitted? Should returning an object from a function be allowed when the object class has a private copy constructor?

Bedroom

Answer 1

Officially, no, RVO/NRVO do not affect whether a program is well formed or not. The standard explicitly allows any side effects from the copy constructor to be omitted, but access checking on the copy constructor is still supposed to be done.

Most compilers, however, will no do access checking on omitted copy constructors unless you ask for the rules to be enforced as strictly as possible. I'm not absolutely sure, but I seem to recall having used a few that skipped the access check even when you did ask for strict compliance (but I don't remember for sure).

Edit (to correct what I see as a misconception expressed in some of the other answers):

The paragraphs in a section of the standard are intended to be read in order. The requirements in the first paragraph that apply to a situation always apply. In this case, the permission to omit side effects is in paragraph 15. Immediately before that in paragraph 14, however, we see that:

A program is ill-formed if the copy constructor or the copy assignment operator for an object is implicitly used and the special member function is not accessible (clause 11).

So, we only get to paragraph 15 (where copying can be omitted) if the access check specified in paragraph 14 has already been passed.

Bruin

Answer 2

The copying is omitted if the optimization takes effect, but the compiler is still required to check that the copy constructor is accessible. Otherwise the code would be invalid in case the compiler (or some other compiler) decided not to optimize.

Quag

Answer 3

Is the copying itself omitted or is the copy constructor invokation omitted?

The copying operation itself is ommitted. If you have a look at the full quote it clearly mentions so:

C++ 03 12.8 copying class objects

Para 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 implemen-tation 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.111)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.....

Should returning an object from a function be allowed when the object class has a private copy constructor?

RVO and NRVO are compiler optimizations, allowed by the compiler but not guaranteed What happens if a particular dumb compiler cannot provide these optimizations?
Without a accessible copy constructor the code will break on all such compilers which is not desired. Given that the copy constructor should be accessible.

Selfassurance

Answer 4

It's the copy itself that is omitted. Whenever copying is actually done, it must be done using the copy constructor, but there are several cases where the compiler is allowed to optimize away a copy.

Larger and non-pod objects are returned by the stack. The caller prepares a space for the object and passes pointer to that space as hidden parameter. The callee than copies the object into that space. Two optimizations can be done here:

1. The callee can create the object directly in the return space. The compiler has to be sure the object is going to be returned, that is only return statements returning that object may follow and intervening code must not throw.
2. If the result is assigned to variable, the caller may pass it's address instead of creating a temporary. This can only be done if the variable is either being initialized or if the effect would provably not differ from calling operator=, which is basically if the type has default constructor, destructor and operator=.

Lin

Answer 5

Is the copying itself omitted or is the copy constructor invokation omitted?

The idea is that the copy constructor is omitted, although the compiler is allowed to share the memory if it doesn't change the program's semantics.

Should returning an object from a function be allowed when the object class has a private copy constructor?

No, it's not allowed. "Should it" is hard to say, but allowing it would allow you to do all sorts of shenanigans and break encapsulation. In C++11 you can sort of do this by using {} construction in the return and move constructing that value.

Enlarge

-1: Misleading. It is the copy that is omitted. A copy must always be done using copy constructor, otherwise all hell would break loose. The "should it" is easy to say, no, it shouldn't, because the compiler does not have to optimize the copy away, so it has to be possible to do it. – Lin

Answer 6

If you look at this article NRVO revealed in MSDN

You will see that no copy coinstructor called.

Cordon