简体   繁体   中英

returning constant object and assigning it to non-constant object

I've found strange behavior of a code which is apparently ignoring const-ness:

#include <iostream>

using std::cerr;

class A
{
public:
    A() { cerr << "A::A()\n"; }
    A(const A &a) { cerr << "A::A(const A&)\n"; }
    A(A &&) { cerr << "A::A(A&&)\n"; }
    A & operator = (const A &a) { cerr << "A::operator=(const A&)\n"; return *this; }
    A & operator = (A &&a) { cerr << "A::operator(A&&)\n"; return *this; }
    ~A() { cerr << "A::~A()\n"; }

    const A get() const { cerr << "const A A::get() const\n"; return A(); }
    A get() { cerr << "A A::get()\n"; return A(); }
};

int main()
{
    const A a;
    A b = a.get();
}

Firstly, what I did expect here: a is a constant, so the constant-version of get() is invoked. Next, constant object is being returned, but on the left side is non-constant object b , so the copy-constructor is ought to be called. Which is not:

A::A()
const A A::get() const
A::A()
A::~A()
A::~A()

Is this behavior expected by c++ standard? So, is it okay that constness of a temporary object is simply ignored by RVO? And how copying could be enforced here?

Output with copy-elision disabled ( -fno-elide-constructors ) makes an additional move and the expected copy-constructor call:

A::A()
const A A::light_copy() const
A::A()
A::A(A&&)
A::~A()
A::A(const A&)
A::~A()
A::~A()
A::~A()

If a object is not constant, then it will be two moves without copying, which is expected too.

PS. The behavior matters for me because the one I see is breaking shallow-copying const-strictness: for const-version of get() (which is shallow_copy() actually) I need to be sure that no modification of the returned object will be made, because the returned object is a shallow copy and a modification on the shallow copy will affect the "parent" object (which might be a constant).

So, is it okay that constness of a temporary object is simply ignored by RVO?

Yes. [class.copy]/p31 (quoting N4527, which incorporates some DRs that clarifies the intent; emphasis mine):

This elision of copy/move operations, called copy elision, 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 nonvolatile automatic object (other than a function parameter or a variable introduced by the exception-declaration of a handler (15.3)) with the same type (ignoring cv-qualification) as the function return type, the copy/move 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/moved to a class object with the same type (ignoring cv-qualification) , the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
  • [...]

The third bullet is the one applicable here; note that a similar rule applies to NRVO (first bullet) as well.

If you want to forbid construction/assignation from const temporary, you may mark as deleted these methods:

A(const A &&) = delete;
A& operator = (const A &&) = delete;

Live Demo

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM