C++ Copy Generators Call

Asked 2 years ago, Updated 2 years ago, 69 views

#include <iostream>
using namespace std;

class SoSimple
{
private:
    int num;
public:
    SoSimple(int n) : num(n)
    {
        cout << "New Object : " << this << endl;
    }
    SoSimple(const SoSimple& copy) :num(copy.num)
    {
        cout << "New Copy obj: " << this << endl;
    }
    ~SoSimple()
    {
        cout << "Destory obj: " << this << endl;
    }
};

SoSimple SimpleFuncObj(SoSimple ob)
{
    cout << "Parm ADR: " << &ob << endl;
    return ob;
}

int main(void)
{
    SoSimple obj(7);
    SimpleFuncObj(obj);

    cout << endl;

    SoSimple tempRef = SimpleFuncObj(obj);
    cout << "Return Obj " << &tempRef << endl;

    return 0;
}

SoSimple tempRef = SimpleFuncObj(obj);

 I thought SimpleFuncObj(obj) would be copied with tempRef here, but it didn't.
As a result of searching here and there, the compiler does not generate a tempRef for efficiency
Is it supposed to be like that?

c++ copy-constructor

2022-09-22 21:38

1 Answers

Which value do you mean you don't copy?

The execution results show that the copy creator is called. (The following is the case with the g++ compiler:)

New Object : 0x7ffffb3509f0      <-- SoSimple obj(7)
New Copy obj: 0x7ffffb350a10 <-- Invoke copy generator to copy obj factor of SimpleFuncObj);
Parm ADR: 0x7ffffb350a10
New Copyobj: 0x7ffffb350a00 <-- Copy generator for return of SimpleFuncObj
Destination obj: 0x7ffffb350a00 <-- Destroy SimpleFuncObj results by not assigning them 
Destination obj: 0x7ffffb350a10 <-- Destruction of the obj factor in SimpleFuncObj

New Copyobj: 0x7ffffb350a20 <-- Call copy constructor to copy obj factor of second SimpleFuncObj
Parm ADR: 0x7ffffb350a20    
New Copyobj: 0x7ffffb3509e0 <-- Copy generator for return of the second SimpleFuncObj
Destination obj: 0x7ffffb350a20 <-- Destruction of the obj factor in the second SimpleFuncObj
Return Obj 0x7ffffb3509e0
Destination obj: 0x7ffffb3509e0 <-- Destroy tempRef after receiving the result of the second SimpleFuncObj
Destination obj: 0x7ffffb3509f0 <-- Destruction of the first obj (7)

Correction answer The gist of the question seems to be as follows.

SoSimple copied = original;

In the above case, the copy generator is called to generate the copied.

SoSimple copied = SimpleFuncObj(obj);

Then, even in the above case, shouldn't we call the copy generator to copy the returned result of SimpleFuncObj(obj) to copied? But why don't you only create a copy generator when you return, and call a copy generator to copy what you return to copied?"

Aside from the compiler optimization problem, this can be explained in many ways, but it can be explained as if it were read in a book, and in other ways, it can be explained simply

When returned by SimpleFuncObj(...), the copied object exists in a temporary state. This is because at the moment of return, it has not yet been decided who points to this object. By the way, you want to assign this temporary object to copied. Literally, this temporary object is not referenced by anyone, so it's going to disappear right away. Is it necessary to copy these temporary objects? According to the previous assign (=), you will copy the object you want to destroy. But wouldn't it be better to have a temporary object called by the name on the left side of the assign (=), rather than copying an object that will disappear because there is no reference anyway? (This is possible because there is no possibility of temporary objects being used elsewhere without passing through the assignment. If you can identify multiple places at the same time when you return, it would be right to call the copy generator as the questioner thought.)

Mechanically, it is related to the execution stack. The description of this is covered in operating system or compiler theory. It's easy to understand if you think about how the execution stack works, but for now, it's just the first paragraph.


2022-09-22 21:38

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.