I wrote a small test program with a sample class containing also self-defined constructor, destructor, copy constructor and assignment operator. I was surprised when I realized that the copy constructor was not called at all, even though I implemented functions with return values of my class and lines like Object o1; Object o2(o1);
innerclass.hpp:
#include <iostream>
class OuterClass
{
public:
OuterClass()
{
std::cout << "OuterClass Constructor" << std::endl;
}
~OuterClass()
{
std::cout << "OuterClass Destructor" << std::endl;
}
OuterClass(const OuterClass & rhs)
{
std::cout << "OuterClass Copy" << std::endl;
}
OuterClass & operator=(const OuterClass & rhs)
{
std::cout << "OuterClass Assignment" << std::endl;
}
class InnerClass
{
public:
InnerClass() : m_int(0)
{
std::cout << "InnerClass Constructor" << std::endl;
}
InnerClass(const InnerClass & rhs) : m_int(rhs.m_int)
{
std::cout << "InnerClass Copy" << std::endl;
}
InnerClass & operator=(const InnerClass & rhs)
{
std::cout << "InnerClass Assignment" << std::endl;
m_int = rhs.m_int;
return *this;
}
~InnerClass()
{
std::cout << "InnerClass Destructor" << std::endl;
}
void sayHello()
{
std::cout << "Hello!" << std::endl;
}
private:
int m_int;
};
InnerClass innerClass()
{
InnerClass ic;
std::cout << "innerClass() method" << std::endl;
return ic;
}
};
innerclass.cpp:
#include "innerclass.hpp"
int main(void)
{
std::cout << std::endl << "1st try:" << std::endl;
OuterClass oc;
OuterClass oc2(oc);
oc.innerClass().sayHello();
std::cout << std::endl << "2nd try:" << std::endl;
OuterClass::InnerClass ic(oc.innerClass());
ic = oc.innerClass();
}
Output:
1st try:
OuterClass Constructor
OuterClass Copy
InnerClass Constructor
innerClass() method
Hello!
InnerClass Destructor
2nd try:
InnerClass Constructor
innerClass() method
InnerClass Constructor
innerClass() method
InnerClass Assignment
InnerClass Destructor
InnerClass Destructor
OuterClass Destructor
OuterClass Destructor
After some research I read that there is no guarantee that the compiler will use the explicitely defined copy constructor. I do not understand this behavior. Why does the copy constructor even exist then, if we do not know that it is called? How does the compiler decide if it uses it?
Or, even better, is there a way to force the compiler to use the self-defined copy constructor?
Just for completeness with the other answers, the standard allows the compiler to omit the copy constructor in certain situations (what other answers refer to as "Return Value Optimization" or "Named Return Value Optimization" - RVO/NRVO):
12.8 Copying class objects, paragraph 15 (C++98)
Whenever a temporary class object is copied using a copy constructor, and this object and the copy have the same cv-unqualified type, an implementation is permitted to treat the original and the copy as two different ways of referring to the same object and not perform a copy at all, even if the class copy constructor or destructor have side effects. For a function with a class return type, if the expression in the return statement is the name of a local object, and the cv-unqualified type of the local object is the same as the function return type, an implementation is permitted to omit creating the temporary object to hold the function return value, even if the class copy constructor or destructor has side effects. In these cases, the object is destroyed at the later of times when the original and the copy would have been destroyed without the optimization.
So in your innerClass() method, the copy constructor you might think would be called at the return is permitted to be optimized away:
InnerClass innerClass() {
InnerClass ic;
std::cout << "innerClass() method" << std::endl;
return ic; // this might not call copy ctor
}
I agree with Neil, you should not write a class which depends on the copy constructor being called. Namely because the compiler can do things like "Named Return Value Optimization" (link) which completely avoids the copy constructor in many return value scenarios. In order to enforce calling the copy constructor you'd need to write a lot of code aimed at "tricking" the C++ compiler. Not a good idea.
In a particular scenario though if you want to enforce calling the copy constructor, you can do an explicit call.
Object SomeFunc() {
Object o1 = ...
return Object(o1);
}
You should not design your class with a reliance on the copy constructor being called (or not called) in specific circumstances. The compiler is allowed to elide or add copy constructor calls at all sorts of places, and you really don't want to have to keep track of them.
As for why you need one - well, the compiler may decide it needs a copy, and the copy constructor is what it uses to do so. The advantage of copy constructor calls being elided is performance - copying is usually quite an expensive operation.
Is this the problem ?
OuterClass(const OuterClass & rhs)
{
std::cout << "OuterClass Constructor" << std::endl;
==>
std::cout << "OuterClass Copy Constructor" << std::endl;
}
OuterClass & operator=(const OuterClass & rhs)
{
std::cout << "OuterClass Constructor" << std::endl;
==>
std::cout << "OuterClass Assignment operator" << std::endl;
}
A copy paste error!
I would suggest you to debug the code once to see what exactly is happening. Debugging really helps you to find the problems.
EDIT: for inner class issue:
As others have already pointed out this is the case of The Name Return Value Optimization(NRVO).
InnerClass innerClass()
{
InnerClass ic;
std::cout << "innerClass() method" << std::endl;
return ic;
}
the compiler can transforms the function to
void innerClass( InnerClass &namedResult)
{
std::cout << "innerClass() method" << std::endl;
}
Thus it eliminates both the return by value of the class object and the need to invoke the class copy constructor.
Please go through below two links to understand more on NRVO:
MSDN NRVO
Stan Lippman's BLog
Object o1(); doesn't create any objects rather it defines a function prototype with function name o1, void arguments and return type as Object. You need to post some code to find the actual problem.
Post some code. I think you are using some incorrect syntax.
The copy constructor must exactly have the following signature:
MyObject(const MyObject&)
Then you can see if the copy constructor is called with the following code:
MyObject m1;
MyObject m2(m1);
You are not allowed to use MyObject m1(); that is a function declaration.
Related
let's say I'm working with an idiomatic Cpp library (e.g. Intel's TBB) and have an in-place member in some class (e.g. TsCountersType _ts_counters;). Such member is automatically initialized by its default constructor (if it exists, otherwise compile error) unless my own KMeans's constructor initialize it explicitely by calling its constructor directly.
Then if I assign a new (created by calling constructor) value to the member field in a normal non-constructor method (e.g. init), what exactly is safe to assume?
I know that in that case the right side of the assignment is rvalue and thus move assignment operator will be called.
I think it is safe to assume that well behaving idiomatic Cpp code should call the original objects's (e.g. _ts_counters) destructor before moving the new object to the memory location. But is such assumption sound?
What about default move assignment operator? Does it call destructor on the original object before moving in? Is that even relevant question or is default move assignment operator created by the compiler only if (among other conditions) no explicit destructor is defined?
If that's the case what happens if I have a scenario similar to the TBB one where instead of TsCountersType I have simple custom tipe with a single unique_ptr and default everything else (constructors, destructors, move assignments, …). When will the unique_ptr get out of scope then?
Specifically in TBB's case, can I assume it happens given their documentation: Supported since C++11. Moves the content of other to *this intact. other is left in an unspecified state, but can be safely destroyed.
Example code:
class KMeans
{
private:
//...
// thread specific counters
typedef std::pair<std::vector<point_t>, std::vector<std::size_t>> TSCounterType;
typedef tbb::enumerable_thread_specific<TSCounterType> TsCountersType;
TsCountersType _ts_counters;
public:
//...
KMeans() : _tbbInit(tbb::task_scheduler_init::automatic) {}
virtual void init(std::size_t points, std::size_t k, std::size_t iters)
{
// When _ts_counters is replaced by a new object the destructor is automatically called on the original object
_ts_counters = TsCountersType(std::make_pair(std::vector<point_t>(k), std::vector<std::size_t>(k)));
}
};
Consider this code:
#include<iostream>
struct S
{
S() { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S(S const &) { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S(S&&) { std::cout << __PRETTY_FUNCTION__ << std::endl;}
S& operator=(S const &) { std::cout << __PRETTY_FUNCTION__ << std::endl; return *this;}
S& operator=(S&&) { std::cout << __PRETTY_FUNCTION__ << std::endl; return *this;}
~S() { std::cout << __PRETTY_FUNCTION__ << std::endl; }
};
struct W
{
W() : s{} {}
void init() { s = S{}; }
private:
S s;
};
int main()
{
W w{};
w.init();
}
The output this produces (clang and gcc tested):
S::S()
S::S()
S &S::operator=(S &&)
S::~S()
S::~S()
So, what happens exactly:
W's constcructor is called, which default initializes S
A temporary S is default constructed and immediately moved from into W::s member
Temporary object is now destructed (just before init exits)
W::s is destructed on main exit.
Mechanism for this is well explained here: Template "copy constructor" does not prevent compiler-generated move constructor, but I would like to better undestand why it is made this way. I understand that move constructor is not generated even if any other constructor is written by the programmer, because it is an indication that construction of object is non trivial and auto generated constructor will probably be wrong. Then why templated constructors that have the same signature as copy constructors are not simply named copy constructors?
Example:
class Person {
public:
template<typename T>
Person(T&& t) : s(std::forward<T>(t)) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
Person(int n) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
// No need to declare copy/move constructors as compiler will do this implicitly
// Templated constructor does not inhibit it.
//Person(const Person&) = default;
//Person(Person&&) = default;
private:
std::string s;
};
and then:
Person p("asd"); // OK!
//Person p4(p); // error as Person(T&&) is a better match
if I make p const:
const Person p("asd");
Person p4(p); // thats ok, generator constructor is a better match
but if I explicitly delete even a move constructor with:
Person(Person&&) = delete;
then auto generation of constructors is inhibited.
You understand wrong.
struct noisy {
noisy() { std::cout << "ctor()\n"; }
noisy(noisy&&) { std::cout << "ctor(&&)\n"; }
noisy(noisy const&) { std::cout << "ctor(const&)\n"; }
noisy& operator=(noisy&&) { std::cout << "asgn(&&)\n"; return *this; }
noisy& operator=(noisy const&) { std::cout << "asgn(const&)\n"; return *this; }
};
struct test {
noisy n;
test(int x) { (void)x; }
};
test has generated move/copy construct/assignment.
Live example.
A copy/move construct/assignment written by a programmer results in the other ones being suppressed.
Now, writing a constructor suppresses the zero-argument constructor. That may be why you are confused.
Templated constructors with the same signature as copy constructors are not copy constructors because the standard says so.
As it happens, templated code is rarely the correct code for a copy or move constructor/assignment.
The fact that forwarding references often grab self& and self const&& copy/move over the actual copy/move operations is a problem. C++ isn't perfect.
Usually the way to avoid this is:
template<class T,
class=std::enable_if_t<
!std::is_same<std::decay_t<T>, Person>::value
>
>
Person(T&& t) : s(std::forward<T>(t)) {
std::cout << __PRETTY_FUNCTION__ << "\n";
}
or !std::is_base_of<Person, std::decay_t<T>>::value which covers some other situations (like inheriting constructors).
When i run the following program in XCode Version 5.1.1,
#include <iostream>
class MyClass
{
public:
MyClass() { std::cout << "MyClass Cons " << this << std::endl;}
~MyClass() { std::cout << "MyClass Dest " << this << std::endl;}
};
void Func(MyClass myClass)
{
}
int main(int argc, const char * argv[])
{
MyClass myClass1;
Func(myClass1);
return 0;
}
The output i get is
MyClass Cons 0x7fff5fbff918
MyClass Dest 0x7fff5fbff910
MyClass Dest 0x7fff5fbff918
Why is the destructor triggering twice and constructor only once?
The object is destroyed once, as you can see from the pointer values. You also see the destruction of another object. This object is a copy of the original.
By passing the object by value, the copy-constructor is invoked. Since this constructor does not print something, you do not see it in your output.
Add it to the class definition:
MyClass(const MyClass & other) { std::cout << "MyClass Copy-Cons " << this << " from " << &other << std::endl;}
And it should appear:
MyClass Cons 0x7fff1beee7ee
MyClass Copy-Cons 0x7fff1beee7ef from 0x7fff1beee7ee
MyClass Dest 0x7fff1beee7ef
MyClass Dest 0x7fff1beee7ee
The copy is created when you enter Func(). The copy is destroyed when it goes out of scope. This happens when you exit Func(). Finally, the original is destroyed when you exit the main() function.
The reason that you are seeing two destructor is because you are pass the arguments by value. Passing by value calls the copy constructor..
First Destructor:
At the end of the func function, the object goes out of scope, hence, it is destructed.
Second Destructor:
When the program end, the object is destructed.
My suggestion to remove the first destructor is to pass the object by reference rather than by value.
For example,
void Func(MyClass &myClass)
{
}
So now the output will have only:
MyClass Cons 0x7fff5fbff918
MyClass Dest 0x7fff5fbff918
Here the object is constructed twice(as everyone mentioned above). Hence 2 constructor + 2 destructor are called. The reason you are seeing 1 constructor is because you have NOT defined the Copy Constructor. CC is called when a copy is made for the pass-by-value operation.
add the copy constructor and then you can see both the constructor called.
Add Copy constructor - MyClass(const MyClass& obj) { std::cout << "MyClass Copy Cons " << this << std::endl;}
This question already has answers here:
Why is the destructor of the class called twice?
(5 answers)
Closed 9 years ago.
#include <iostream>
using namespace std;
class A
{
public:
A() { cout << "A's constructor" << endl; }
~A() { cout << "A's destructor" << endl; }
};
class B
{
public:
operator A() const { return A(); }
};
void f(A q) {}
int main()
{
B d1;
f(d1);
return 0;
}
Here's what I expected the code to do before I ran it:
The call to f results in a call to the converter function in class B which returns a temporary object. q's constructor gets called and when f exits, q's destructor gets called. I expected the following output:
A's constructor
A's destructor
but the output I got was:
A's constructor
A's destructor
A's destructor
Since there's another destructor, an extra object must have been created somewhere. Can someone explain what's happening here?
Use this as your class A:
class A
{
public:
A() { cout << "A's constructor: " << this << endl; }
A(const A& a) { cout << "A's copy constructor: " <<this << " form " << &a << endl; }
A(A&& a) { cout << "A's move constructor: " <<this << " form " << &a << endl; }
A& operator=(const A& a) { cout << "A's assignment" <<this << " form " << &a << endl; }
~A() { cout << "A's destructor: "<< this << endl; }
};
And you'll see why.
The question has been asked many times before, but since it is so generic it is difficult to find the older posts.
You are passing your objects around by value, meaning that the copies are created by copy constructor. Copy constructor is what created that "extra object" in your case. Meanwhile, you do not output anything from the copy constructor and therefore don't see the calls.
You have to add a debug output to your copy-constructor as well. That way you will see what is actually constructed and when.
There's potential for there to be 3 A objects constructed here. First is the temporary object created by A() in the conversion operator. Then, since the return type of the conversion operator is A, that temporary is copied into the return value. Then the return value of the conversion is copied into the parameter q of f.
To copy an object, the copy constructor is invoked. The default constructor will not be invoked, so you won't see the "A's constructor" message being printed.
It just so happens that the compiler elides one of these copies so that you only actually have one copy occur. Which one is being elided, I can't tell you (but it's probably the copy into the return value).
I think first destructor call for temporary object and second destructor for object which is constructed by move semantic.
Question is probably pretty basic, but can't find out what's wrong (and it leads to huge of memleaks in my app):
class MyClass {
public:
MyClass() { cout << "constructor();\n"; };
MyClass operator= (const MyClass& b){
cout << "operator=;\n"; return MyClass();
};
~MyClass() { cout << "destructor();\n"; };
};
main() {
cout << "1\n";
vector<MyClass> a;
cout << "2\n";
MyClass b;
cout << "3\n";
a.push_back(b);
cout << "4\n";
}
The output is:
1
2
constructor();
3
4
destructor();
destructor();
Why are there 2 destructors?
If it's because a copy is created to be inserted into vector - how come "operator=" is never called?
When the b object gets pushed onto the vector a copy is made, but not by the operator=() you have - the compiler generated copy constructor is used.
When the main() goes out of scope, the b object is destroyed and the copy in the vector is destroyed.
Add an explicit copy constructor to see this:
MyClass( MyClass const& other) {
cout << "copy ctor\n";
};
If you want to log all copies and constructions you should add an explicit copy constructor so that the compiler doesn't create one for you.
MyClass( const MyClass& )
{
cout << "Copy constructor\n";
}
You can, in your copy constructor, call your assignment operator. It is a reasonably common way of implementing things, however with your definition of operator=, this may have serious problems.
You have an unconventional implementation of operator=. operator= should return a reference to the class on which it is called (to enable proper chaining), but you return a new class instance by value. This means that if you tried to call operator= from your copy constructor you may well end up with infinite recursion. Try this operator= instead:
MyClass& operator=( const MyClass& )
{
cout << "operator=\n";
return *this;
}
When defining an assignment operator you should always consider the possibility that the parameter and *this may refer to the same object and ensure that the definition of the operator won't have any unintended effects in this scenario.