Change constructor order of operations? - c++

I have the following sample code, and the copy assignment is doing something I don't want - it's first constructing the new samp(6), then copying it to z, then destroying the new samp(6) it built. Is there a way to change the constructors such that = acts like a pointer, destroying the originally constructed samp(5) and replacing it with the new samp(6), calling the destructor on samp(5), rather than samp(6)?
#include <iostream>
class samp
{
public:
samp(int a)
{
m_a = a;
std::cout << "cons" <<m_a << std::endl;
}
int m_a;
samp(const samp& other)
{
std::cout << "copy" << m_a << std::endl;
m_a = other.m_a;
}
samp& operator= (const samp& other)
{
std::cout << "assg" << m_a << std::endl;
samp* z =new samp(other.m_a);
return *z;
}
~samp()
{
std::cout << "dest" <<m_a<< std::endl;
}
};
int main()
{
samp z(5);
z = samp(6);
std::cout << z.m_a << std::endl;
return 0;
}

Maybe pointer semantics is what you want:
#include <memory>
// ...
auto z = std::make_unique<samp>(5);
z = std::make_unique<samp>(6); // dest5
std::cout << z->m_a << '\n'; // 6
Although if you are coming to C++ from a language where object names are object references, it may be better to get used to C++ value semantics instead of trying to replicate object references :)

operator= is a member of your object so the this pointer is available. Also, assignment means the target of the assignment should change. Your version is creating a new object, but leaving the target alone. See if this does what you want:
samp& operator= (const samp& other)
{
m_a = other.m_a;
return *this;
}

Related

How values of member variables are getting copied even though copy constructor is not getting called due to RVO in C++

I am not able to understand how the values of member variables are getting copied even though the constructor is not getting called in the below program.
#include <iostream>
using namespace std;
class myclass
{
public:
int x;
int y;
myclass(int a, int b)
{
cout << "In Constructor" << endl;
x = a;
y = b;
}
~myclass()
{
cout << "In Destructor" << endl;
}
myclass(const myclass &obj)
{
cout << "In Copy Constuctor " << obj.x << " " << obj.y << endl;
x = obj.x;
y = obj.y;
}
myclass &operator=(const myclass &obj)
{
cout << "In Operator Overloading" << obj.x << obj.y << endl;
x = obj.x;
y = obj.y;
return *this;
}
};
int main()
{
myclass obj1 = myclass(2, 3);
cout << "obj1.x : " << obj1.x << "obj1.y" << obj1.y << endl;
}
Output:
In Constructor
obj1.x : 2obj1.y3
In Destructor
I understood that due to Return Value Optimization, copy constructor is not getting called. But I didn't understand how obj1 is getting values 2 and 3. Can any one please help me to understand this or how Return Value Optimization will work behind the scenes.
The values aren't getting copied, because they don't need to be copied. Instead, the values which would have been copied are initialized in place. Copy elision means that the compiler essentially turns this:
myclass obj1 = myclass(2, 3);
Into this:
myclass obj1(2, 3);
So no extra object is constructed which needs to be copied.
Note that RVO, which you've referred to, is a form of copy elision. But this specific case of copy elision is not RVO.

Immutable objects in C++11 and move semantics

I'm trying to create an immutable class in C++11, which (for convenience) provides methods that modify the current state. To satisfy the immutable contract, these methods must return a new instance with the updated contents.
In the following snippet, ImmutableObject::setA() and ImmutableObject::setB() update the a and b attributes in a new instance of ImmutableObject created via a copy constructor and return it. The method print() just displays the content.
int main(int argc, char **argv) {
ImmutableObject().setA(1).setB(2).print();
return 0;
}
(An implementation of ImmutableObject is provided below.)
Implementing this naively using C++03 causes an unnecessary copies to be created.
I am wondering if C++11 move semantics can be used to exploit the fact that ImmutableObject() and the return value of setA() are just temporary copies that could be directly updated.
I already added a rvalue copy and assignment constructor in the code below, but it does not look like it's working. When running the program, I get
In constructor
In copy constructor
In copy constructor
a=1, b=2
Any advice would be greatly appreciated!
#include <iostream>
using namespace std;
class ImmutableObject {
public:
ImmutableObject() {
std::cout << "In constructor" << std::endl;
}
ImmutableObject(const ImmutableObject &obj) : a(obj.a), b(obj.b) {
std::cout << "In copy constructor" << std::endl;
}
ImmutableObject(ImmutableObject&& other) {
std::cout << "In move constructor" << std::endl;
a = other.a;
b = other.b;
}
ImmutableObject &operator=(ImmutableObject&& other) {
if (this != &other) {
a = other.a;
b = other.b;
}
return *this;
}
ImmutableObject setA(int value) {
ImmutableObject result(*this);
result.a = value;
return result;
}
ImmutableObject setB(int value) {
ImmutableObject result(*this);
result.b = value;
return result;
}
void print() {
std::cout << "a=" << a << ", b=" << b << std::endl;
}
private:
int a;
int b;
};

const value and RVO

Say I have this function:
template <class A>
inline A f()
{
A const r(/* a very complex and expensive construction */);
return r;
}
Is it a good idea to declare r const, since a const variable cannot be moved? Note that the returned value is not const. The qualm I am grappling is, that r truly is const, but it may not be a good idea to declare it as such. Yet the qualifier should be helping the compiler generate better code.
As demonstrated here, NRVO elides the copy of r implied by the line return r;
#include <iostream>
struct A {
const char* name;
A( const char* name_ ):name(name_) { std::cout << "created " << name << "\n"; }
A(A const&){ std::cout << "copied " << name << "\n"; }
A(A &&){ std::cout << "moved " << name << "\n"; }
};
A f() {
std::cout << "start of f()\n";
A const r("bob");
std::cout << "body of f()\n";
return r;
}
int main() {
A x = f();
}
And the copy in main is also elided.
If you block NRVO and RVO in some other way (for instance using the flag -fno-elide-constructors when compiling with GCC), the const can cause your object to be copied instead of moved. You can see this if we remove the copy constructor from A:
#include <iostream>
struct A {
const char* name;
A( const char* name_ ):name(name_) { std::cout << "created " << name << "\n"; }
//A(A const&){ std::cout << "copied " << name << "\n"; }
A(A &&){ std::cout << "moved " << name << "\n"; }
};
A f() {
std::cout << "start of f()\n";
A const r("bob");
std::cout << "body of f()\n";
return r;
}
int main() {
A x = f();
}
the code no longer compiles. While the copy constructor isn't executed so long as NRVO occurs, its existence is required by your const local variable.
Now, NRVO requires a few things, such as a single variable which is returned along every single execution path of the function in question: if you ever "abort" and do a return A(), NRVO is blocked, and your const local variable suddenly forces a copy at all return sites.
If class A is under your control, and you want to return const objects by move, you can do
mutable bool resources_were_stolen = false;
and set that to true in a const move constructor
A(const A&& other) { ...; other.resources_were_stolen = true; }
~A() { if (!resources_were_stolen) ... }
Actually, the destructor probably would become if (resources_were_stolen) some_unique_ptr.release();, using the fact that objects lose their const-ness during construction and destruction.

Returning pointer by value does not move the object

I have compiled this code with vs2011. It prints first constructor then copy constructor.
But if I change the function to return a instead of ap, it will move the object. Is this a bug or why does it behave like this? Is *ap not a rvalue?
struct A
{
A() { cout << "constructor" << endl;}
A(const A&) { cout << "copy constructor " << endl;}
void operator=(const A&) { cout << "assignment operator" << endl; }
A( A&&) { cout << "move copy constructor" << endl;}
void operator=(A&&) { cout << "move assignment operator" << endl;}
};
A func() { A a; A *ap = &a; return *ap; }
int main()
{
A a = func();
return 0;
}
*ap is an lvalue (ยง 5.3.1.1, n3290) which is in general not safe for the move to happen automatically. The local variable return a; is a different case. There's no requirement for the compiler to prove that in this specific instance it would be safe. This is another good reason for not using pointers in cases where you don't really want pointer semantics.
Changing it to:
return std::move(*ap);
will cause it to be explicitly moved however.

How can I get the address of initializer?

The code below introduces a class C. The class has constructor, copy constructor, operator= and one member. How can I get the address of the object created by C(2) in the function main()?
#include <iostream>
class C
{
public:
int a;
C(const C &other)
{
std::cout << "Copy Constructor:" << a << std::endl;
}
C(int a)
{
this->a = a;
std::cout << "Constructor:" << a << std::endl;
}
C &operator=(const C &other)
{
std::cout << "operator=:this.a = " << a << " | other.a = " << other.a << std::endl;
a = other.a;
return *this;
}
~C()
{
std::cout << "Destructor:" << a << std::endl;
}
};
int main()
{
C a(1);
a = C(2);
}
You can't. You are forbidden from taking addresses of temporaries. They will go out of scope very quickly, leaving you with an invalid address.
You could use a helper function to write the address somewhere before the object goes out of scope:
template <typename T>
T const & store_possibly_invalid_address(T const & t, T const *& p)
{
p = &t;
return t;
}
int main()
{
C a(1);
C const * invalid_address;
a = store_possibly_invalid_address(C(2), invalid_address);
// The temporary is out of scope, but you can see where it was.
// Don't dereference the pointer.
}
That could be educational, to discover where the compiler chooses to put temporaries. It has no purpose in any real code, though.
The only way is with some collaboration inside the class; the
constructor has the address (the this pointer), and can put it
somewhere where you can get at it later. I'd recommend against it,
though, since the object won't live long enough for you to do much with
it. (On the other hand, it's sometimes useful for debugging to output
it.)