CConstructor Infinite Recursion!

**Elysia** · 12-22-2010

The containers stores copies of what you feed them, so obviously it calls the copy constructor to make copies of what you put in.

**Eman** · 12-22-2010

Originally Posted by Elysia

The containers stores copies of what you feed them, so obviously it calls the copy constructor to make copies of what you put in.

Yeah i know, except the declaration is:

push_back(const T&)

it only copies the reference of the object. Since it isn't copying the object itself
there is no reason for the invocation copy constructor.

**Elysia** · 12-22-2010

The actual copying happens later. Typically the code creates a new T, which is given its value from what you put in. You need to do some more digging.

**Eman** · 12-22-2010

Originally Posted by Elysia

The actual copying happens later. Typically the code creates a new T, which is given its value from what you put in. You need to do some more digging.

so a new object is created, the copy constructor copies the values to the new object. The reference of the new T is passed to push_back.... ?

that sounds like a waste...

i tried going deeper. but i couldn't read the _Insert function definition.

**kmdv** · 12-22-2010

It is something like that:

Your program:
1. Creates your A object, initializes it, etc
2. Pushes reference to A (its address)
3. Calls push_back

push_back:
1. Pops the reference passed
2. Creates new node for the list
3. It cannot store reference in the list, because the object, created by your program, may be destroyed after returning from push_back, thus it needs to place a copy of A in the node

Your program:
4. When it gets back from the push_back, the reference passed is destroyed, the copy of A in the node remains, your program may destroy the original object

What cannot you understand else?

**Eman** · 12-22-2010

Originally Posted by kmdv

It is something like that:

Your program:
1. Creates your A object, initializes it, etc
2. Pushes reference to A (its address)
3. Calls push_back

push_back:
1. Pops the reference passed
2. Creates new node for the list
3. It cannot store reference in the list, because the object, created by your program, may be destroyed after returning from push_back, thus it needs to place a copy of A in the node

Your program:
4. When it gets back from the push_back, the reference passed is destroyed, the copy of A in the node remains, your program may destroy the original object

What cannot you understand else?

That was pretty clear thanks.
so at push_back stage 3, the CCtor is invoked. Fair enough, just thought it was a bit odd.
Thanks.

**Elysia** · 12-22-2010

Again, a reference its not an address! You can't push back the address of a reference! Nor can you pop it!

**Eman** · 12-22-2010

Originally Posted by Elysia

Again, a reference its not an address! You can't push back the address of a reference! Nor can you pop it!

11: References & the Copy-Constructor

"A reference is a fancy pointer..."

an address of the object is passed to the variable, except the compiler does the job of dereferencing it for us.

**Elysia** · 12-22-2010

Is a random site you found on internet a trust worthy source? Please cite the standard instead.

**Eman** · 12-22-2010

Originally Posted by Elysia

Is a random site you found on internet a trust worthy source? Please cite the standard instead.

Ok i can't find the website for a C++ standard. But I am sure Microsoft no matter how cr*p their software is, use it.

Reference Operator: & (C++)

main point:
"A reference holds the address of an object but behaves syntactically like an object"

**Elysia** · 12-22-2010

Again, how references are implemented is implementation defined. Microsoft has chosen the way you described. That doesn't mean all other compiler vendors will.

**Eman** · 12-22-2010

Originally Posted by Elysia

Again, how references are implemented is implementation defined. Microsoft has chosen the way you described. That doesn't mean all other compiler vendors will.

yeah I am trying to unlearn that

.

By the way, maybe what kmdv meant by
"pops the reference"

was actually
"makes a reference?"

**iMalc** · 12-22-2010

Originally Posted by Eman

What do you mean, what is useless?

Because it's like the hotel california...

You can put a string in it, but can never get it out again.

**kmdv** · 12-22-2010

I was thinking about pushing / poping parameters from the stack. I should have mentioned the stack. Parameters can also be passed via registry or be eliminated. The point was to explain how it works and give a brief overview. I prefer explaining things giving a concrete example (here a specific platform) as I said it is 'something' like that. Standard can be very confusing.

**whiteflags** · 12-22-2010

Em. Does anyone know why a pushing an object into a list invokes the copy constructor?
I just had a glance at the api and noticed it takes a reference to an object. So it shouldn't invoke it, but it does?

Now, remember, the STL requires copyable objects. So what does this mean? Well, you were already told that this:

Code:

void push_back ( const T &x )
{
    T newNode( x );
}

would be virtually the same as copying it here:

Code:

void push_back ( T x )

Hopefully you understand why it's important that the STL is in charge of deleting the stuff they contain. That's why you bother with copies at all. Additionally, I think the STL only uses the first version because push_back can accept the return value of another function, which is nice, and the references avoid unnecessary copying. There is a name for what exactly happens in a situation like that which I don't care to remember, but I think that is the design rationale at work here.

Optimizing compilers may fail to make a real difference between either version but remember vendors have to support a standard interface. So in summary, if you want to use the STL containers, have them contain copyable and assignable objects. Now just keep in mind what you've learned about the copy constructor and assignment operator (specifically, when you have to write your own) and you should be OK.