Why need a copy ctor inside a vector<T> (3)

Hi, can anyone help me why a copy constructor is needed? I was thinking why not use all default constructor to reduce the actions?

1
2
cout << "CONSTRUCTING VECTOR WITH THREE ELEMENTS";
vector<Element> d( 3 );


The output is

1
2
3
4
5
6
CONSTRUCTING VECTOR WITH THREE ELEMENTS
In default constructor
In copy constructor
In copy constructor
In copy constructor
In destructor


Thanks!
vector's constructor optionally takes a constructed object so you can do something like this:

 
vector<Element> d( 3, Element(xxx) );


vector then builds itself using that supplied Element by copying that supplied Element to each of the 3 entries.

If you don't supply a specific Element, the same code is used, only a default constructed object is used. That is:

1
2
3
vector<Element> d( 3 );
// is the same as
vector<Element> d( 3, Element() );


The vector takes the default constructed element and copies it 3 times into the vector.



But none of this should matter. A properly written copy constructor should be in consequential. The details of how vector may or may not be implemented shouldn't have any impact on your code. Just make sure you have valid copy ctors and assignment operators (or if not, then make sure the compiler-supplied versions will work) and you won't have any problems.
Thanks for the reply.

I'm wondering why would the given code above be implemented with the use of a copy constructor. I thought c/c++ is about efficiency, speed, terseness...

Would it be correct then for me to think that the above code was implemented inefficiently by the compiler?

Thanks again.
I'm wondering why would the given code above be implemented with the use of a copy constructor


I can't explain it any better than I did in my previous post.

I thought c/c++ is about efficiency, speed, terseness...


A properly written copy constructor is just as fast as reconstructing the same object every time.

In a lot of cases, copy ctors are even faster. As is the case in reference counted objects.

But even in non-reference counted objects, it's often faster to copy an object than it is to reconstruct an object from scratch. Reconstruction might involve some additional computation, whereas a straight copy is pretty much always very simple.

Would it be correct then for me to think that the above code was implemented inefficiently by the compiler?


No.
There is a reason. The vector( size_t n ) constructor guarantees that, upon completion, the following
is true: v[ 0 ] == v[ 1 ] == ... == v[ n ]. This guarantee cannot be made by running the default
constructor N times. Consider an object whose default constructor stores a unique instance ID for
the object (or a timestamp).
I now get it. Thanks for the explanation guys.
EDIT: I should say that vector's constructor wants to guarantee that. There is no reasonable expectation
that running the default constructor multiple times will generate identical objects. There isn't a hard guarantee
that running the copy constructor multiple times will do that either, but at least that's what a copy constructor
is supposed to do.
Thanks again.

What I understand from your explanation is that the implementation above is more on creating duplicate/same objects rather than how to create objects of the same type the the shortest way. If my understanding is true, then the implementation above is now clear to me.
The point is that there is no expectation that two default constructed elements are "the same", therefore the only
choice of implementation is to default construct once and copy N times. I didn't read that that was your
understanding from your statement.
Thanks for the reply.

From your first reply, what I understood was that the reason the copy ctor was used over the default ctor was because the default ctor can not generate the same objects if the objects have unique instance IDs. And I believe it's true.

My last post was about what I thought was the criterion that was more favored by the implementation. I thought that it could also be implemented using only the default ctor.

For example, what if it would be used more often with objects that have no instance-specific data? I guess being a beginner, I can think much more of objects that have no instance-specific IDs than objects with instance-specific IDs. With this, I think that it would be faster to implement with executing the default ctor a number of times than with using a default ctor and then copying a number of times.
Disch wrote:
A properly written copy constructor is just as fast as reconstructing the same object every time.

In a lot of cases, copy ctors are even faster. As is the case in reference counted objects.
For example, what if it would be used more often with objects that have no instance-specific data? I guess being a beginner, I can think much more of objects that have no instance-specific IDs than objects with instance-specific IDs. With this, I think that it would be faster to implement with executing the default ctor a number of times than with using a default ctor and then copying a number of times.


But the implementer of std::vector<> doesn't know that your object can be default constructed multiple times and produce identical objects every time. It has everything to do with correctness (or at least providing semantics that aren't surprising to the user) and
nothing to do with speed.
For example, what if it would be used more often with objects that have no instance-specific data?


If the objects contain no instance specific data, why would you need a vector of them?
Thanks again to the replies

@jsmith
I agree with you. I think that was what I was trying to say? in
the implementation above is more on creating duplicate/same objects rather than how to create objects of the same type the the shortest way



@dsisch
I might have stated it incorrectly. Anyways, I was referring to those data (e.g. timestamp) in jsmith's first reply, which could cause different results from a default ctor and a copy ctor.
Topic archived. No new replies allowed.