"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
news:ll5GHNiwKr+EFwtw@robinton.demon.co.uk...
> In article <4ltdbvF3fguoU1@individual.net>, Matthias Hofmann
> <hofmann@anvil-soft.com> writes
>>"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
>>news:D6Y$QFC6uc9EFwBN@robinton.demon.co.uk...
>>> In article <4ll3adF2b73pU1@individual.net>, Matthias Hofmann
>>> <hofmann@anvil-soft.com> writes
>>>>I do not have the C++03 draft of the standard available
>>>
>>> It is not a draft, it is the current C++ Standard.
>>
>>It is officially called a "technical corrigendum", and a draft of the
>>combined C++98 standard and corrigendum is not yet publically available.
>>See
>>
>>http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882
> Did you read the first paragraph at the above link. It not only states
> that a draft is available but gives you a link.

Yes, and the link is password protected.

--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Graeme Prentice wrote:
> On Thu, 31 Aug 2006 09:44:17 CST, "kanze" <kanze@gabi-soft.fr> wrote:

> >Alberto Ganesh Barbati wrote:
> >> Matthias Hofmann ha scritto:
> >> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsbeitrag
> >> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
> >> >> Matthias Hofmann ha scritto:

> >> > Given that, the expression

> >> > T arr[N] = {};

> >> > should require an accessible constructor that takes a T as
> >> > its argument.  This can be a copy constructor or a template
> >> > constructor.

> >> Incorrect. As I already wrote in another post, every element
> >> of the array is simply value-initialized.

> >That's what it says in    8.5.1/7. No one is disputing that, and
> >the differences between default-initialization and
> >value-initialization aren't relevant here (since neither uses
> >the copy constructor).

> >The defect is that in    8.5/12, the standard says explicitly that
> >copy-initialization (not value-initialization or
> >default-initialization) is used.  Which is a direct
> >contradiction with    8.5.1/7.

> >Given both statements, the question is whether for missing
> >initializers, the statement in    8.5/12 doesn't hold (although I
> >can't see any reason why not), or whether the intent is that
> >value-initialization be used to create an initializer (which is
> >then used according to the rule in    8.5/12).  I think that both
> >interpretations are possible, with the second probably closer to
> >the meaning of the exact words in the standard.

> I disagree.  It's perfectly clear that items with missing
> initializers are value-initialized.  For value initialization,
> the terms copy-initialize or direct-initialize are meaningless
> so when 8.5/12 mentions copy-initialization, it's also clear
> that it is referring to items that do not have missing
> initializers i.e. there is an implied "for members that are
> explicitly initialized" in 8.5/12.

That seems a bit exterpolated.  There is no (or should not be
any) "implied" in standard text.  This whole discussion got
started (in comp.lang.c++.moderated) because I read    8.5/12, and
based my statements on it, whereas others read    8.5.1/7.  The
two paragraphs say contradictory things concerning the
initialization.  You can remove the contradiction by adding an
additional clause to the sentance in    8.5/12, as you propose
(but this clause is currently not present), or by slightly
modifying    8.5.1/7, to make it clear that what is
value-initialized is the initialization expression, as the
non-normative note suggests.

> 12.6.1/2 also says <quote>
> When an aggregate (whether class or array) contains members of
> class type and is initialized by a braceenclosed
> initializer-list (8.5.1), each such member is copy-initialized
> (see 8.5) by the corresponding assignment-expression. If there
> are fewer initializers in the initializer-list than members of
> the aggregate, each member not explicitly initialized shall be
> value-initialized (8.5 <end quote>

And that is clearly a defect.  There is NO assignment-expression
(clause    5.17) in an initialization (unless it is embedded in
the initialization expression, of course).

Still, the fact that in one (or several) place(s) in the
standard, it says that value initialization is used, doesn't
change the fact that in another place, it says that copy
initialization is used, and that the example in one of the
places says value-initialization makes it clear that the
*intent* (at least in this one place---I'm not sure that the
standard is consistent about this) is that value-initialization
be used to get the initialization value.

> Well, having read these paragraphs dozens of times, it's
> certainly clear to me, but not necessarily to a first time
> reader.  But then the standard isn't aimed at first time
> readers.

   8.5/12 is very clear.  As is    8.5.1/7 without the text
accompanying the example, and    12.6.1/2.  The problem is that
the first clearly says one thing, and the others clearly say
something different.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Tue,  5 Sep 2006 09:59:01 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Graeme Prentice wrote:
>> On Thu, 31 Aug 2006 09:44:17 CST, "kanze" <kanze@gabi-soft.fr> wrote:
>
>> >Alberto Ganesh Barbati wrote:
>> >> Matthias Hofmann ha scritto:
>> >> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Ne=
wsbeitrag
>> >> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
>> >> >> Matthias Hofmann ha scritto:
>
>> >> > Given that, the expression
>
>> >> > T arr[N] =3D {};
>
>> >> > should require an accessible constructor that takes a T as
>> >> > its argument.  This can be a copy constructor or a template
>> >> > constructor.
>
>> >> Incorrect. As I already wrote in another post, every element
>> >> of the array is simply value-initialized.
>
>> >That's what it says in =A78.5.1/7. No one is disputing that, and
>> >the differences between default-initialization and
>> >value-initialization aren't relevant here (since neither uses
>> >the copy constructor).
>
>> >The defect is that in =A78.5/12, the standard says explicitly that
>> >copy-initialization (not value-initialization or
>> >default-initialization) is used.  Which is a direct
>> >contradiction with =A78.5.1/7.
>
>> >Given both statements, the question is whether for missing
>> >initializers, the statement in =A78.5/12 doesn't hold (although I
>> >can't see any reason why not), or whether the intent is that
>> >value-initialization be used to create an initializer (which is
>> >then used according to the rule in =A78.5/12).  I think that both
>> >interpretations are possible, with the second probably closer to
>> >the meaning of the exact words in the standard.
>
>> I disagree.  It's perfectly clear that items with missing
>> initializers are value-initialized.  For value initialization,
>> the terms copy-initialize or direct-initialize are meaningless
>> so when 8.5/12 mentions copy-initialization, it's also clear
>> that it is referring to items that do not have missing
>> initializers i.e. there is an implied "for members that are
>> explicitly initialized" in 8.5/12.
>
>That seems a bit exterpolated.  There is no (or should not be
>any) "implied" in standard text.  This whole discussion got
>started (in comp.lang.c++.moderated) because I read =A78.5/12, and
>based my statements on it, whereas others read =A78.5.1/7.  The
>two paragraphs say contradictory things concerning the
>initialization.  You can remove the contradiction by adding an
>additional clause to the sentance in =A78.5/12, as you propose

I didn't propose anything.


>(but this clause is currently not present), or by slightly
>modifying =A78.5.1/7, to make it clear that what is
>value-initialized is the initialization expression, as the
>non-normative note suggests.

Exactly which non-normative note do you think suggests that?  Perhaps
you mean the non-normative example in 5.7/1


>
>> 12.6.1/2 also says <quote>
>> When an aggregate (whether class or array) contains members of
>> class type and is initialized by a braceenclosed
>> initializer-list (8.5.1), each such member is copy-initialized
>> (see 8.5) by the corresponding assignment-expression. If there
>> are fewer initializers in the initializer-list than members of
>> the aggregate, each member not explicitly initialized shall be
>> value-initialized (8.5 <end quote>
>
>And that is clearly a defect.  There is NO assignment-expression
>(clause =A75.17) in an initialization (unless it is embedded in
>the initialization expression, of course).

Not true.  An assignment expression does not have to contain an
assignment operator.  Check out 5.17/1 and 8.5/1.



>
>Still, the fact that in one (or several) place(s) in the
>standard, it says that value initialization is used, doesn't
>change the fact that in another place, it says that copy
>initialization is used, and that the example in one of the
>places says value-initialization makes it clear that the
>*intent* (at least in this one place---I'm not sure that the
>standard is consistent about this) is that value-initialization
>be used to get the initialization value.

The standard says very clearly and in more than one place that the
member is value initialized.  In no place does it say that an
initializer is created with value initialization.

The non-normative example is very slightly misleading (but not
incorrect), since value initialization of a POD member (int in this
case) means that member is zero-initialized and zero-initialization
for a scalar type such as int is defined in 8.5/5 where it says=20

<quote> if T is a scalar type (3.9), the object is set to the value of
0 (zero) converted to T  <end quote>

so int() is certainly the value used to initialize the int member as
the example says but it's misleading because it suggests that for any
member of type T, T() is used to initialize the object, which is not
true because the normative text says the member is value initialized.
It would be better if the example said "and ss.c is zero-initialized
i.e. set to zero".


>
>> Well, having read these paragraphs dozens of times, it's
>> certainly clear to me, but not necessarily to a first time
>> reader.  But then the standard isn't aimed at first time
>> readers.
>
>=A78.5/12 is very clear.  As is =A78.5.1/7 without the text
>accompanying the example, and =A712.6.1/2.  The problem is that
>the first clearly says one thing, and the others clearly say
>something different.

Since there are two types of initialiization that can occur with brace
enclosed initializer lists, it's reasonable to expect the reader to
realize that 8.5/12 is referring to members that have an explicit
initializer.

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Graeme Prentice wrote:
> On Tue,  5 Sep 2006 09:59:01 CST, "kanze" <kanze@gabi-soft.fr> wrote:
> >Graeme Prentice wrote:
> >> On Thu, 31 Aug 2006 09:44:17 CST, "kanze" <kanze@gabi-soft.fr> wrote:

> >> >Alberto Ganesh Barbati wrote:
> >> >> Matthias Hofmann ha scritto:
> >> >> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsbeitrag
> >> >> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
> >> >> >> Matthias Hofmann ha scritto:

> >> >> > Given that, the expression

> >> >> > T arr[N] = {};

> >> >> > should require an accessible constructor that takes a T as
> >> >> > its argument.  This can be a copy constructor or a template
> >> >> > constructor.

> >> >> Incorrect. As I already wrote in another post, every element
> >> >> of the array is simply value-initialized.

> >> >That's what it says in    8.5.1/7. No one is disputing that, and
> >> >the differences between default-initialization and
> >> >value-initialization aren't relevant here (since neither uses
> >> >the copy constructor).

> >> >The defect is that in    8.5/12, the standard says explicitly that
> >> >copy-initialization (not value-initialization or
> >> >default-initialization) is used.  Which is a direct
> >> >contradiction with    8.5.1/7.

> >> >Given both statements, the question is whether for missing
> >> >initializers, the statement in    8.5/12 doesn't hold (although I
> >> >can't see any reason why not), or whether the intent is that
> >> >value-initialization be used to create an initializer (which is
> >> >then used according to the rule in    8.5/12).  I think that both
> >> >interpretations are possible, with the second probably closer to
> >> >the meaning of the exact words in the standard.

> >> I disagree.  It's perfectly clear that items with missing
> >> initializers are value-initialized.  For value initialization,
> >> the terms copy-initialize or direct-initialize are meaningless
> >> so when 8.5/12 mentions copy-initialization, it's also clear
> >> that it is referring to items that do not have missing
> >> initializers i.e. there is an implied "for members that are
> >> explicitly initialized" in 8.5/12.

> >That seems a bit exterpolated.  There is no (or should not be
> >any) "implied" in standard text.  This whole discussion got
> >started (in comp.lang.c++.moderated) because I read    8.5/12, and
> >based my statements on it, whereas others read    8.5.1/7.  The
> >two paragraphs say contradictory things concerning the
> >initialization.  You can remove the contradiction by adding an
> >additional clause to the sentance in    8.5/12, as you propose

> I didn't propose anything.

Let's say that doing so corresponds to your interpretation.

> >(but this clause is currently not present), or by slightly
> >modifying    8.5.1/7, to make it clear that what is
> >value-initialized is the initialization expression, as the
> >non-normative note suggests.

> Exactly which non-normative note do you think suggests that?
> Perhaps you mean the non-normative example in 5.7/1

Yes (supposing you meant    8.5.1/7---5.7/1 seems an obvious
typo).  It explicitly speaks of initializing the element with
the "value of an expression of the form int()".  Which is highly
suggestive that the default-initialization/value-initialization
is meant to define the value used for initialization, not for
the initialization itself.

It's not really that important, of course, except perhaps for
intent.  The normative text is quite clear, both here and in
   8.5/12.  Clear, but contradictory.

> >> 12.6.1/2 also says <quote>
> >> When an aggregate (whether class or array) contains members of
> >> class type and is initialized by a braceenclosed
> >> initializer-list (8.5.1), each such member is copy-initialized
> >> (see 8.5) by the corresponding assignment-expression. If there
> >> are fewer initializers in the initializer-list than members of
> >> the aggregate, each member not explicitly initialized shall be
> >> value-initialized (8.5 <end quote>

> >And that is clearly a defect.  There is NO assignment-expression
> >(clause    5.17) in an initialization (unless it is embedded in
> >the initialization expression, of course).

> Not true.  An assignment expression does not have to contain an
> assignment operator.  Check out 5.17/1 and 8.5/1.

Sorry, I confounded the two.

In fact, of course, this statement basically just repeats the
normative text in    8.5.1/7.

> >Still, the fact that in one (or several) place(s) in the
> >standard, it says that value initialization is used, doesn't
> >change the fact that in another place, it says that copy
> >initialization is used, and that the example in one of the
> >places says value-initialization makes it clear that the
> >*intent* (at least in this one place---I'm not sure that the
> >standard is consistent about this) is that value-initialization
> >be used to get the initialization value.

> The standard says very clearly and in more than one place that the
> member is value initialized.  In no place does it say that an
> initializer is created with value initialization.

The standard also says very clearly that when there is a brace
enclosed initialization list, copy-initialization is used.

Nobody is disputing that the standard sometimes says that
value-initialization should be used.  The problem is that in
other places, it contradicts this, and says that
copy-initialization is used.  And when the standard contradicts
itself, it is a defect.

> The non-normative example is very slightly misleading (but not
> incorrect), since value initialization of a POD member (int in this
> case) means that member is zero-initialized and zero-initialization
> for a scalar type such as int is defined in 8.5/5 where it says

> <quote> if T is a scalar type (3.9), the object is set to the value of
> 0 (zero) converted to T  <end quote>

> so int() is certainly the value used to initialize the int member as
> the example says but it's misleading because it suggests that for any
> member of type T, T() is used to initialize the object, which is not
> true because the normative text says the member is value initialized.
> It would be better if the example said "and ss.c is zero-initialized
> i.e. set to zero".

I agree that there is no ambiguity in the normative text.  The
example suggests, at most, that the normative text perhaps
doesn't correspond to what the authors intended to say.
Perhaps, only.

The problem, however, is not one of ambiguity; it is one of a
contradiction between two unambiguous statements.

> >> Well, having read these paragraphs dozens of times, it's
> >> certainly clear to me, but not necessarily to a first time
> >> reader.  But then the standard isn't aimed at first time
> >> readers.

> >   8.5/12 is very clear.  As is    8.5.1/7 without the text
> >accompanying the example, and    12.6.1/2.  The problem is that
> >the first clearly says one thing, and the others clearly say
> >something different.

> Since there are two types of initialiization that can occur
> with brace enclosed initializer lists,

The problem is that    8.5/12 says that there is only one type of
initialization that occurs with brace enclosed initializer
lists.

> it's reasonable to expect the reader to realize that 8.5/12 is
> referring to members that have an explicit initializer.

Except that it doesn't make any exceptions.  It says quite
clearly that the initialization is copy-initialization.  It is
part of the definition of copy-initialization.  (The fact that
the term copy-initialization is in italics means that this is
the defininition.)  Copy-initialization is the initialization
which occurs in brace-enclosed initializer lists.  Not in
"brace-enclosed initializer lists for the objects with an
explicit initializer", but in "brace-enclosed initializer
lists", period.  If the initialization occurs in a
brace-enclosed initializer list, it is copy-initialization, and
it is equivalent to the form T x = a;.

That is what    8.5/12 says, and I don't see any way it can be
interpreted differently.  I totally agree that in other places,
the standard says something different; that is a contradiction
in the standard, and a contradiction is a defect.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Jens Theisen wrote:
> Alberto Ganesh Barbati wrote:
> > If you read carefully 8.5, you will see that the, despite
> > the name, copy-initialization does not necessarily require a
> > copy constructor.

> I just read it and it seems that

> X x = X();

> doesn't despite the common belief that it does. Am I reading
> this correctly?

I don't know.  I can't figure out where anyone is finding this.
It would seem to me that the standard is quite clear: this is
the equivalent of:

    X x( X() ) ;

and that certainly needs a copy constructor.

> > You are referring to an old version of the standard. The
> > 2003 version reads differently

> Interesting. Is this the draft of the new C++0x, or indeed an
> update of C++98? I would have thought that this is clearly
> distinguished and DRs for C++98 still refer to the old
> standard.

The latest draft does word things differently, but I don't see
where it changes this precise point.

> > I agree that the name copy-initialization is confusing and
> > the whole initialization process is in some cases complex
> > and possibly unintuitive, but apart from that, the standard
> > is very clear, IMHO.

> The old standard was contradicting itself, IMHO, but can only
> be interpreted in one sensible way as I see it (that being the
> latter correction of Matthias' DR).

The latest draft also contradicts itself.  And I'm not sure
about any one way of interpreting it being more sensible than
the other.

> > As we saw above, the array member is going to be
> > value-initialized.

> My standard doesn't contain that term, I guess it's a C++0x
> thing?

Yes, but it comes out more or less to the same thing in this
context.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <wyJJg.89544$zy5.1495200@twister1.libero.it>, Alberto Ganesh
Barbati <AlbertoBarbati@libero.it> writes
>Does it make sense?

Possibly but this whole area is under intense review for C++0x

>

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> kanze ha scritto:

> > The defect is that in    8.5/12, the standard says explicitly
> > that copy-initialization (not value-initialization or
> > default-initialization) is used.  Which is a direct
> > contradiction with    8.5.1/7.

> I see. It really seems to me that the whole problem is just a
> matter of unfortunately chosen terms. As I see it, the terms
> zero-initialization, default-initialization and
> value-initialization are all defined abstractly, without
> references to a particular syntax, and correspond to precise
> initialization algorithms described in 8.5/5. Oppositely, the
> terms direct-initialization and copy-initialization name
> *syntaxes* and do *not* correspond to proper initialization
> algorithms. They are just used as "conditions" to make choices
> inside the complex algorithm described in 8.5/14.

That's an interesting point.

My impression, however, is that whether an initialization is a
copy-initialization or a direct-initialization is a semantic
issue (necessity of a copy constructor, etc.); the other
distinctions don't.     8.5/12 specifies in which cases the
semantics are those of direct-initialization and which are
copy-initialization.  Default-initialization and
value-initialization can in principal be either
direct-initialization or copy-initialization.  (Or do they have
their own semantics.  If so, the standard is very vague about
it.)  In the case of missing initializers at the end of a brace
enclosed initializer list, we have value-initialization which
has semantics of copy-initialization, where as in most (all?)
other cases, it has direct-initialization semantics.

> Maybe we should replace the terms direct-initialization and
> copy-initialization with direct-initialization-syntax and
> copy-initialization-syntax, respectively.

The problem at hand is to choose the semantics which are needed
for a specific syntax.  I agree that it would be better if the
terms weren't linked to the syntax used to specify them in the
usual case, but the fact remains that these two initializations
can both be invoked in many different cases---the only real
difference is the semantics.

> I think that would clarify a lot. In particular, it would no
> longer be a surprise to know that an initializer in
> copy-initialization *syntax* might eventually *perform* a
> value-initialization.

> Does it make sense?

Not really.  It seems opposite to what the standard currently
says.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <SpZJg.90503$zy5.1500623@twister1.libero.it>, Alberto Ganesh
Barbati <AlbertoBarbati@libero.it> writes
>Francis Glassborow ha scritto:
>> In article <wyJJg.89544$zy5.1495200@twister1.libero.it>, Alberto Ganesh
>> Barbati <AlbertoBarbati@libero.it> writes
>>> Does it make sense?
>>
>> Possibly but this whole area is under intense review for C++0x
>>
>
>So it's the perfect time to discuss about it, isn't it?

But start by reading the papers that already exist.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
news:1157030182.313575.260550@p79g2000cwp.googlegroups.com...
> Jens Theisen wrote:
>> Alberto Ganesh Barbati wrote:
>> > If you read carefully 8.5, you will see that the, despite
>> > the name, copy-initialization does not necessarily require a
>> > copy constructor.
>
>> I just read it and it seems that
>
>> X x = X();
>
>> doesn't despite the common belief that it does. Am I reading
>> this correctly?
>
> I don't know.  I can't figure out where anyone is finding this.
> It would seem to me that the standard is quite clear: this is
> the equivalent of:
>
>    X x( X() ) ;
>
> and that certainly needs a copy constructor.

Not for the following definition of X:

struct X
{
    // Default constructor.
    X() {};

    // Copy constructor.
    X( X& ) { std::cout <<
        "X( X& )" << std::endl; };

    // Template constructor.
    template <class T>
    X( const T& ) { std::cout <<
        "X( const T& )" << std::endl; }
};

Note that the copy constructor takes a non-constant reference while the
template constructor takes a constant reference.

There was a similar discussion in comp.lang.c++.moderated titled "Template
conversion and default copy constructor" starting on July 21st, 2006.

--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
news:D6Y$QFC6uc9EFwBN@robinton.demon.co.uk...
> In article <4ll3adF2b73pU1@individual.net>, Matthias Hofmann
> <hofmann@anvil-soft.com> writes
>>I do not have the C++03 draft of the standard available
>
> It is not a draft, it is the current C++ Standard.

It is officially called a "technical corrigendum", and a draft of the
combined C++98 standard and corrigendum is not yet publically available. See

http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882

So it seems that C++98 is still the current standard.

--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <4ltdbvF3fguoU1@individual.net>, Matthias Hofmann
<hofmann@anvil-soft.com> writes
>"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
>news:D6Y$QFC6uc9EFwBN@robinton.demon.co.uk...
>> In article <4ll3adF2b73pU1@individual.net>, Matthias Hofmann
>> <hofmann@anvil-soft.com> writes
>>>I do not have the C++03 draft of the standard available
>>
>> It is not a draft, it is the current C++ Standard.
>
>It is officially called a "technical corrigendum", and a draft of the
>combined C++98 standard and corrigendum is not yet publically available. See
>
>http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882
Did you read the first paragraph at the above link. It not only states
that a draft is available but gives you a link. However BSI has
certainly published the corrected standard and the printed version from
Wiley also provides it.

A TC is the document that corrects a Standard. After a TC has been
issued the Standard is the original + TC. Whether ISO reissues the
Standard with the TC incorporated is a separate decision. In addition
every NB can reissue its version (as BSI chose to do) with the TC
incorporated.

>
>So it seems that C++98 is still the current standard.

No, the current Standard is the 98 document + all subsequent TCs that
have been voted out by ISO. For short hand purposes we normally refer to
The C++ Standard (ISO/IEC 14882:1998 ) + TC 1 as C++03. By whatever name
you like to use, that is the current C++ Standard.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Thu, 31 Aug 2006 09:44:17 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Alberto Ganesh Barbati wrote:
>> Matthias Hofmann ha scritto:
>> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsb=
eitrag
>> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
>> >> Matthias Hofmann ha scritto:
>
>> > Given that, the expression
>
>> > T arr[N] =3D {};
>
>> > should require an accessible constructor that takes a T as
>> > its argument.  This can be a copy constructor or a template
>> > constructor.
>
>> Incorrect. As I already wrote in another post, every element
>> of the array is simply value-initialized.
>
>That's what it says in =A78.5.1/7. No one is disputing that, and
>the differences between default-initialization and
>value-initialization aren't relevant here (since neither uses
>the copy constructor).
>
>The defect is that in =A78.5/12, the standard says explicitly that
>copy-initialization (not value-initialization or
>default-initialization) is used.  Which is a direct
>contradiction with =A78.5.1/7.
>
>Given both statements, the question is whether for missing
>initializers, the statement in =A78.5/12 doesn't hold (although I
>can't see any reason why not), or whether the intent is that
>value-initialization be used to create an initializer (which is
>then used according to the rule in =A78.5/12).  I think that both
>interpretations are possible, with the second probably closer to
>the meaning of the exact words in the standard.


I disagree.  It's perfectly clear that items with missing initializers
are value-initialized.  For value initialization, the terms
copy-initialize or direct-initialize are meaningless so when 8.5/12
mentions copy-initialization, it's also clear that it is referring to
items that do not have missing initializers i.e. there is an implied
"for members that are explicitly initialized" in 8.5/12. =20

12.6.1/2 also says <quote>
When an aggregate (whether class or array) contains members of class
type and is initialized by a braceenclosed initializer-list (8.5.1),
each such member is copy-initialized (see 8.5) by the corresponding
assignment-expression. If there are fewer initializers in the
initializer-list than members of the aggregate, each member not
explicitly initialized shall be value-initialized (8.5=20
<end quote>


Well, having read these paragraphs dozens of times, it's certainly
clear to me, but not necessarily to a first time reader.  But then the
standard isn't aimed at first time readers.

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Thu, 31 Aug 2006 09:44:17 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Alberto Ganesh Barbati wrote:
>> Matthias Hofmann ha scritto:
>> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsb=
eitrag
>> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
>> >> Matthias Hofmann ha scritto:
>
>> > Given that, the expression
>
>> > T arr[N] =3D {};
>
>> > should require an accessible constructor that takes a T as
>> > its argument.  This can be a copy constructor or a template
>> > constructor.
>
>> Incorrect. As I already wrote in another post, every element
>> of the array is simply value-initialized.
>
>That's what it says in =A78.5.1/7. No one is disputing that, and
>the differences between default-initialization and
>value-initialization aren't relevant here (since neither uses
>the copy constructor).
>
>The defect is that in =A78.5/12, the standard says explicitly that
>copy-initialization (not value-initialization or
>default-initialization) is used.  Which is a direct
>contradiction with =A78.5.1/7.
>
>Given both statements, the question is whether for missing
>initializers, the statement in =A78.5/12 doesn't hold (although I
>can't see any reason why not), or whether the intent is that
>value-initialization be used to create an initializer (which is
>then used according to the rule in =A78.5/12).  I think that both
>interpretations are possible, with the second probably closer to
>the meaning of the exact words in the standard.

I disagree.  It's perfectly clear that items with missing initializers
are value-initialized.  For value initialization, the terms
copy-initialize or direct-initialize are meaningless so when 8.5/12
mentions copy-initialization, it's also clear that it is referring to
items that do not have missing initializers i.e. there is an implied
"for members that are explicitly initialized" in 8.5/12. =20

12.6.1/2 also says <quote>
When an aggregate (whether class or array) contains members of class
type and is initialized by a braceenclosed initializer-list (8.5.1),
each such member is copy-initialized (see 8.5) by the corresponding
assignment-expression. If there are fewer initializers in the
initializer-list than members of the aggregate, each member not
explicitly initialized shall be value-initialized (8.5=20
<end quote>


Well, having read these paragraphs dozens of times, it's certainly
clear to me, but not necessarily to a first time reader.  But then the
standard isn't aimed at first time readers.

Graeme

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Section 8.5/12 says: "The initialization that occurs in [...] and
brace-enclosed initializer lists is called copy-initialization, and is
equivalent to the form  T x = a;", which seems to require an accessible copy
constructor in the expression

T arr[N] = {};

However, section 8.5.1/7 says: "If there are fewer initializers in the list
than there are members in the aggregate, then each member not explicitly
initialized shall be default-initialized (8.5)."

Now the problem is that the standard requires copy-initialization, while not
providing for an object to be copied. Perhaps the intent is that only
explicit initializers in the list are copy-initialization, but the standard
is not clear here.

The question is whether in

T arr[1] = {};

the object is copy initialized with a temporary that is in turn default
initialized, such as in

T arr[1] = { T() };

or whether no temporary is created, and the object that is default
initialized is 'arr[0]' rather than a temporary.

--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Matthias Hofmann" wrote:
> Section 8.5/12 says: "The initialization that occurs in [...] and
> brace-enclosed initializer lists is called copy-initialization, and is
> equivalent to the form  T x = a;", which seems to require an accessible copy
> constructor in the expression
>
> T arr[N] = {};
>
> However, section 8.5.1/7 says: "If there are fewer initializers in the list
> than there are members in the aggregate, then each member not explicitly
> initialized shall be default-initialized (8.5)."
>
> Now the problem is that the standard requires copy-initialization, while not
> providing for an object to be copied. Perhaps the intent is that only
> explicit initializers in the list are copy-initialization, but the standard
> is not clear here.
>
> The question is whether in
>
> T arr[1] = {};
>
> the object is copy initialized with a temporary that is in turn default
> initialized, such as in
>
> T arr[1] = { T() };
>
> or whether no temporary is created, and the object that is default
> initialized is 'arr[0]' rather than a temporary.

A third option is possible: copy initialization from a
default-initialized temporary is technically required, and the
existence of an accessible copy constructor is therefore required, but
the copy can be elided as an optimization.  I'm not saying that the
current standard clearly requires (or prohibits) this; just that it's a
possible resolution to the DR.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Matthias Hofmann" wrote:
> Section 8.5/12 says: "The initialization that occurs in [...] and
> brace-enclosed initializer lists is called copy-initialization, and is
> equivalent to the form  T x = a;", which seems to require an accessible copy
> constructor in the expression
>
> T arr[N] = {};
>
> However, section 8.5.1/7 says: "If there are fewer initializers in the list
> than there are members in the aggregate, then each member not explicitly
> initialized shall be default-initialized (8.5)."
>
> Now the problem is that the standard requires copy-initialization, while not
> providing for an object to be copied. Perhaps the intent is that only
> explicit initializers in the list are copy-initialization, but the standard
> is not clear here.
>
> The question is whether in
>
> T arr[1] = {};
>
> the object is copy initialized with a temporary that is in turn default
> initialized, such as in
>
> T arr[1] = { T() };
>
> or whether no temporary is created, and the object that is default
> initialized is 'arr[0]' rather than a temporary.

   8.5/15 clause 6 provides the final, missing step needed to complete
the above analysis.

To recap the line of reasoning so far:

      T array[0] = {};

is equivalent to:

      T array[0] = { T() };

which in turn can be interpreted as:

      T array[0] = T();

which in turn becomes:

      T t = T();

At this point,    8.5/15 provides a dramatic, surprising and satisfying
d   nouement: it turns out that a copy initialization in which the class
of the source object is identical to - or derived from - the class of
the destination object is - in fact - a direct initialization (for all
practical purposes):

      T t(T());

There we have it. To answer the question: there is no copy constructor
needed for T because no copy initialization actually takes place. As a
further consequence, there is no defect in the Standard regarding this
question, since a (very) close reading of a very recent draft of the
Standard does provide the answer.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <44f4b491$0$18484$9b4e6d93@newsspool3.arcor-online.net>, Jens
Theisen <jth02@arcor.de> writes
>> As we saw above, the array member is going to be value-initialized.
>
>My standard doesn't contain that term, I guess it's a C++0x thing?
>
The 2003 amended version does. See 8.5 para 5

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Greg Herlihy" <greghe@pacbell.net> schrieb im Newsbeitrag=20
news:1156920408.341392.291790@h48g2000cwc.googlegroups.com...

> =A78.5/15 clause 6 provides the final, missing step needed to complete
> the above analysis.
>
> To recap the line of reasoning so far:
>
>      T array[0] =3D {};
>
> is equivalent to:
>
>      T array[0] =3D { T() };

Well, this is the question.

> which in turn can be interpreted as:
>
>      T array[0] =3D T();
>
> which in turn becomes:
>
>      T t =3D T();
>
> At this point, =A78.5/15 provides a dramatic, surprising and satisfying
> d=E9nouement: it turns out that a copy initialization in which the clas=
s
> of the source object is identical to - or derived from - the class of
> the destination object is - in fact - a direct initialization (for all
> practical purposes):
>
>      T t(T());

I do not have the C++03 draft of the standard available so I don't know=20
whether there have been changes to the meaning of direct initialization. =
But=20
am I wrong in thinking that direct initialization requires a copy=20
constructor even more than copy initialization? At least if the source an=
d=20
the target types are identical?

--=20
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsbeitrag
news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
> Matthias Hofmann ha scritto:
>> Section 8.5/12 says: "The initialization that occurs in [...] and
>> brace-enclosed initializer lists is called copy-initialization, and is
>> equivalent to the form  T x = a;", which seems to require an accessible
>> copy
>> constructor in the expression
>>
>> T arr[N] = {};
>
> If you read carefully 8.5, you will see that the, despite the name,
> copy-initialization does not necessarily require a copy constructor.
> That is true for both arrays and non-arrays. This is a common
> misunderstanding. There was recently a thread about this on
> comp.lang.c++.moderate.

I remember such a thread, I don't know whether it is the same as the one you
are having in mind. That discussion was about template constructors, and
there I have learned that a template constructor can do the job of a copy
constructor in the case of copy initialization. It was also concluded that
(if the source and target types are not identical) copy initialization is
actually a conversion followed by direct initialization.

Given that, the expression

T arr[N] = {};

should require an accessible constructor that takes a T as its argument.
This can be a copy constructor or a template constructor.

>> However, section 8.5.1/7 says: "If there are fewer initializers in the
>> list
>> than there are members in the aggregate, then each member not explicitly
>> initialized shall be default-initialized (8.5)."
>
> You are referring to an old version of the standard. The 2003 version
> reads differently: "If there are fewer initializers in the list than
> there are members in the aggregate, then each member not explicitly
> initialized shall be value-initialized (8.5)." Notice the
> "value-initialized" instead of the "default-initialized". Naively
> speaking, value-initialization is either default-initialization or
> zero-initialization according to the type of the object and/or the
> presence of user defined constructors.

If I understand this correctly, value-initialization does not involve a copy
constructor. This would make things clear.

> BTW: Always refer to the most recent version of the standard when
> submitting defect reports!

Where can I get a copy of the latest draft?

>> Now the problem is that the standard requires copy-initialization, while
>> not
>> providing for an object to be copied. Perhaps the intent is that only
>> explicit initializers in the list are copy-initialization, but the
>> standard
>> is not clear here.
>
> I agree that the name copy-initialization is confusing and the whole
> initialization process is in some cases complex and possibly
> unintuitive, but apart from that, the standard is very clear, IMHO.

I agree that the C++03 draft seems to be rather clear on that issue.

--
Matthias Hofmann
Anvil-Soft, CEO
http://www.anvil-soft.com - The Creators of Toilet Tycoon
http://www.anvil-soft.de - Die Macher des Klomanagers


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <4ll3adF2b73pU1@individual.net>, Matthias Hofmann
<hofmann@anvil-soft.com> writes
>I do not have the C++03 draft of the standard available

It is not a draft, it is the current C++ Standard.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy wrote:
> "Matthias Hofmann" wrote:
> > Section 8.5/12 says: "The initialization that occurs in
> > [...] and brace-enclosed initializer lists is called
> > copy-initialization, and is equivalent to the form  T x =
> > a;", which seems to require an accessible copy constructor
> > in the expression

> > T arr[N] = {};

> > However, section 8.5.1/7 says: "If there are fewer
> > initializers in the list than there are members in the
> > aggregate, then each member not explicitly initialized shall
> > be default-initialized (8.5)."

> > Now the problem is that the standard requires
> > copy-initialization, while not providing for an object to be
> > copied. Perhaps the intent is that only explicit
> > initializers in the list are copy-initialization, but the
> > standard is not clear here.

> > The question is whether in

> > T arr[1] = {};

> > the object is copy initialized with a temporary that is in
> > turn default initialized, such as in

> > T arr[1] = { T() };

> > or whether no temporary is created, and the object that is
> > default initialized is 'arr[0]' rather than a temporary.

>    8.5/15 clause 6 provides the final, missing step needed to
> complete the above analysis.

> To recap the line of reasoning so far:

One of the lines of reasoning.  The one that puts the statement
in    8.5/12 ahead of the one in 8.5.1/7.

>       T array[0] = {};

> is equivalent to:

>       T array[0] = { T() };

> which in turn can be interpreted as:

>       T array[0] = T();

> which in turn becomes:

>       T t = T();

> At this point,    8.5/15 provides a dramatic, surprising and
> satisfying d   nouement: it turns out that a copy initialization
> in which the class of the source object is identical to - or
> derived from - the class of the destination object is - in
> fact - a direct initialization (for all practical purposes):

>       T t(T());

I'm aware of that, but what does it change?

> There we have it. To answer the question: there is no copy
> constructor needed for T because no copy initialization
> actually takes place.

And what constructor do you use when you initialize an object of
type T with an expression of type T?

> As a further consequence, there is no defect in the Standard
> regarding this question, since a (very) close reading of a
> very recent draft of the Standard does provide the answer.

I'm not sure.  I don't see where the replacement of
default-initialized with value-initialized changes anything.
The problem is that neither default-initialization nore
value-initialization are copy-initializations, so in one place,
the standard still says that copy-initialization will be used,
and in another, that value-initialization will be used.  And it
cannot be both.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> Matthias Hofmann ha scritto:
> > "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> schrieb im Newsbeitrag
> > news:2F%Ig.86371$zy5.1470746@twister1.libero.it...
> >> Matthias Hofmann ha scritto:

> > Given that, the expression

> > T arr[N] = {};

> > should require an accessible constructor that takes a T as
> > its argument.  This can be a copy constructor or a template
> > constructor.

> Incorrect. As I already wrote in another post, every element
> of the array is simply value-initialized.

That's what it says in    8.5.1/7. No one is disputing that, and
the differences between default-initialization and
value-initialization aren't relevant here (since neither uses
the copy constructor).

The defect is that in    8.5/12, the standard says explicitly that
copy-initialization (not value-initialization or
default-initialization) is used.  Which is a direct
contradiction with    8.5.1/7.

Given both statements, the question is whether for missing
initializers, the statement in    8.5/12 doesn't hold (although I
can't see any reason why not), or whether the intent is that
value-initialization be used to create an initializer (which is
then used according to the rule in    8.5/12).  I think that both
interpretations are possible, with the second probably closer to
the meaning of the exact words in the standard.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:

    [...]
>    8.5/15 clause 6 does not apply, because clause 3 "Otherwise,
> if the destination type is an array, see 8.5.1." is in effect.
> The rest of the reasoning is therefore incorrect as it starts
> with a wrong assumption.

Yes and no.  When all is said and done,    8.5.1 says that each
member is initialized with the given expression, which brings us
back to    8.5/15 for the individual members.  And    8.5/12 says
that when reading    8.5 for the individual members, the
initialization is copy-initialization.  (The example in    8.5.1/7
also says that the individual member of type int is initialized
with int().  Regretfully, it's not normative text.)

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Matthias Hofmann" wrote:
> "Greg Herlihy" <greghe@pacbell.net> schrieb im Newsbeitrag
> news:1156920408.341392.291790@h48g2000cwc.googlegroups.com...

> >    8.5/15 clause 6 provides the final, missing step needed to
> > complete the above analysis.

> > To recap the line of reasoning so far:

> >      T array[0] = {};

> > is equivalent to:

> >      T array[0] = { T() };

> Well, this is the question.

> > which in turn can be interpreted as:

> >      T array[0] = T();

> > which in turn becomes:

> >      T t = T();

> > At this point,    8.5/15 provides a dramatic, surprising and
> > satisfying d   nouement: it turns out that a copy
> > initialization in which the class of the source object is
> > identical to - or derived from - the class of the
> > destination object is - in fact - a direct initialization
> > (for all practical purposes):

> >      T t(T());

> I do not have the C++03 draft of the standard available so I
> don't know whether there have been changes to the meaning of
> direct initialization. But am I wrong in thinking that direct
> initialization requires a copy constructor even more than copy
> initialization? At least if the source and the target types
> are identical?

Well, both the latest draft and C++98 say pretty much the same
thing.  And it is, of course, much more complicated than the
simple presentation Greg tried to make.

First, `T t = T()' does not turn into `T t(T())'.  `T t = T()'
is copy-initialization, and `T t( T() )' is direct
initialization (and initialization using a brace enclosed
initializer list is copy-initialization).  This was the case in
C++98, and nothing in the latest draft has changed.

The semantics of initializers are defined in    3.5/14: if we are
speaking of a single initializer of a non-aggregate class type,
there are two cases which concern us: the first defines what
happens in the case of direct initialization or
copy-initialization where the initialization expression has the
same type as the target, or a type derived from it, and the
second concerns the remaining cases of copy-initialization.

The reason for placing copy-initialization with an
initialization expression of the target type is simple; when the
initialization expression has the target type,
direct-initialization already requires a copy constructor (or
rather, a constructor which can be called with an object of type
T---we've been through this before).

The important point is, of course, that the compiler will use
overload resolution to select a constructor to copy the type T,
and that this constructor must be accessible.

Note that there are several other points of wording which might
be relevant:

 -- The third bullet of    8.5/14 says that if the destination
    type is an array, see    8.5.1.  So the first reading of this
    paragraph doesn't even get to the point where we talk about
    how class types are initialized.  (But of course,    8.5/12
    still applies.)

 -- In the latest draft, at least,    8.5.1/8 treats this case
    explicitly: "An empyt initializer-list can be used to
    initialize any aggregate.  If the aggregate is not an empty
    class, then each member of the aggregate shall be
    initialized with a value of the form T(), where T represents
    the type of the uninitialized member."

    At first view, that would seem to make it explicitly clear:
    copy-initialization of the value T().  But of course, it
    would be very surprizing if the initialization in the case
    of an empty list were different from the initialization of
    the remaining members if the list isn't empty.  So if there
    is no copy-initialization for the remaining members, we're
    still in doubt (but it is even clearer that there is a
    defect).

 -- Finally, in    8.5.1/7, we have the example:

            struct S { int a; char* b; int c; };
            S ss = { 1, "asdf" };

        initializes ss.a with 1, ss.b with "asdf", and ss.c with
        the value of an expression of the form int(), that is,
        0.

    Of course, it's an example, in a note, so the text is not
    normative.  But it does suggest that the intent was to use
    value-initialization (or default-initialization, in the
    earlier versions) to define the value to be used for the
    copy-initialization.

All in all, I think that the intent was that copy initialization
be used in all cases.  I also think this logical; it doesn't
make sense to me that:
    T t1[1] = {} ;
and
    T t1[1] = { T() } ;
behave differently.  But IMHO, the standard is far from being
perfectly clear about this, to the point where I think that
there is a defect.  The correction is simple: for    8.5.1/7,
either:

    If there are fewer initializers in the list than there are
    members in the aggregate, then each member not explicitly
    initialized shall be initialized as if there were an
    initializer of the form T() [...]

or:

    If there are fewer initializers in the list than there are
    members in the aggregate, then each member not explicitly
    initialized shall be value-initialized, rather than
    copy-initialized. [Example:

        struct S { int a; char* b; int c; };
        S ss = { 1, "asdf" };

    initializes ss.a with 1, ss.b with "asdf", and ss.c is
    value-initialized (which will result in a value of 0 in this
    case).]

To tell the truth, I don't care which, but I would like to see
it clearly specified.

--
James Kanze                                           GABI Software
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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]