CopyConstructible requirement for standard library containers

[subramanian100in]

Suppose 'Test' is a class.

In order to use 'Test' as element type for a standard library
container, say, vector, 'Test' class must be CopyConstructible and
Assignable.

Does CopyConstructible mean that the class must support both direct-
initialization and copy-initialization ?

Kindly clarify.

Thanks
V.Subramanian

 

[James Kanze]

Suppose 'Test' is a class.

In order to use 'Test' as element type for a standard library
container, say, vector, 'Test' class must be CopyConstructible and
Assignable.

Does CopyConstructible mean that the class must support both
direct- initialization and copy-initialization ?

No. It means that if t is an object of type T (or T const), the
expression T(t) is legal, and results in a new object which is
equivalent to t.

 

[subramanian100in]

Suppose I have kept the copy ctor of the element type T as 'explicit'.
Then, can I say that T is still CopyConstructible ?

Only if the implementation of the particular standard library uses
copy-initialization on some container(vector in this case) operations,
then those operations cannot be performed. Am I correct ?

Kindly clarify.

Thanks
V.Subramanian

 

[James Kanze]

* James Kanze <[email protected]> wrote:

Suppose I have kept the copy ctor of the element type T as 'explicit'.
Then, can I say that T is still CopyConstructible ?

Apparently, according to the text in the standard. I wouldn't
declare a copy constructor explicit, however---I'm not sure what
that means, or even what it should mean, logically.

Only if the implementation of the particular standard library
uses copy-initialization on some container(vector in this
case) operations, then those operations cannot be performed.
Am I correct ?

I'm not sure what you're trying to say, but if I understand
explicit copy constructors correctly, copy initialization isn't
allowed if the copy constructor is explicit. In practice,
however, I don't think it's an issue, since the objects are
passed by reference, and normally "copied" by using an explicit
invocation of placement new (since allocation and initialization
are separated), which is direct initialization.

(BTW: I wouldn't worry about these sort of things unless I were
actually writing a compiler. They just don't affect real code,
and there are a lot of more important issues to be concerned
with.)

 

[James Kanze]

On 2008-09-30 05:59:23 -0400, James Kanze <[email protected]> said:

One implication is this:

T t0;
T t1(t0); // OK: explicit copy construction
T t2 = t0; // error: implicit copy construction

And that's a very good reason not to do it.

That's what I understand as well. But only as a result of some
discussions in the newsgroups. This means that you can't pass
objects with explicit copy constructors to functions, or return
them from functions, which (IMHO) pretty much makes copying
useless (or irrelevant)---perhaps it would make sense if you
only want to support copy so that you can implement some form of
generic clone function. But even that seems exoteric enough
that I wouldn't use it.

It also means, of course, that an implementation of the standard
library cannot pass the instantiation type by value, or return
it, since the requirements are only that the expression T(t) is
legal, and this is the case even if the copy constructor is
explicit.