Re: CopyConstructible requirement for standard library containers

[subramanian100in]

* James Kanze <[e-mail]:

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]

On Sep 30, 8:27 am, "[e-mail], India"
<[e-mail]:

* James Kanze <[e-mail]:

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pete Becker]

On 2008-09-30 05:59:23 -0400, James Kanze <ja*********@gmail.comsaid:

On Sep 30, 8:27 am, "[e-mail], India"
<[e-mail]:

>* James Kanze <[e-mail]:

>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.

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.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

On Sep 30, 12:51 pm, Pete Becker <[e-mail]:

On 2008-09-30 05:59:23 -0400, James Kanze <[e-mail]:

On Sep 30, 8:27 am, "[e-mail], India"
<[e-mail]:

* James Kanze <[e-mail]:

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.

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]