The containers stores copies of what you feed them, so obviously it calls the copy constructor to make copies of what you put in.
You ended that sentence with a preposition...Bastard!
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?
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.
You ended that sentence with a preposition...Bastard!
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"
Last edited by Eman; 12-22-2010 at 11:19 AM.
You ended that sentence with a preposition...Bastard!
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
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.
Last edited by kmdv; 12-22-2010 at 12:43 PM.
Now, remember, the STL requires copyable objects. So what does this mean? Well, you were already told that this: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?
would be virtually the same as copying it here:Code:void push_back ( const T &x ) { T newNode( 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.Code:void push_back ( T x )
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.