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).
A simple rule of thumb that will prevent most cases of “const brokenness” is for const methods to never return pointers to non-const objects.
Constant objects can only call constant member functions. Non-constant objects can call both constant and non-constant member functions. A constant member function can be overloaded with a non-constant version.
The value of a constant can't be changed through reassignment (i.e. by using the assignment operator), and it can't be redeclared (i.e. through a variable declaration). However, if a constant is an object or array its properties or items can be updated or removed.
When a function is declared as const, it can be called on any type of object. Non-const functions can only be called by non-const objects. For example the following program has compiler errors.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With