[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

CopyConstructible requirement for standard library containers

subramanian100in@yahoo.com, India

9/29/2008 3:01:00 PM

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
5 Answers

James Kanze

9/29/2008 4:08:00 PM

0

On Sep 29, 5:00 pm, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> 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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

subramanian100in@yahoo.com, India

9/30/2008 6:28:00 AM

0

* James Kanze <james.ka...@gmail.com> wrote:

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

9/30/2008 9:59:00 AM

0

On Sep 30, 8:27 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> * James Kanze <james.ka...@gmail.com> 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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Pete Becker

9/30/2008 10:51:00 AM

0

On 2008-09-30 05:59:23 -0400, James Kanze <james.kanze@gmail.com> said:

> On Sep 30, 8:27 am, "subramanian10...@yahoo.com, India"
> <subramanian10...@yahoo.com> wrote:
>> * James Kanze <james.ka...@gmail.com> 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.

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

10/1/2008 7:35:00 AM

0

On Sep 30, 12:51 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-09-30 05:59:23 -0400, James Kanze <james.ka...@gmail.com> said:

> > On Sep 30, 8:27 am, "subramanian10...@yahoo.com, India"
> > <subramanian10...@yahoo.com> wrote:
> >> * James Kanze <james.ka...@gmail.com> 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.

> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34