"kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
news:1156770985.946413.321730@74g2000cwt.googlegroups.com...

> Perhaps the intent is that only
> explicit initializers in the list are copy initialization.  If
> so, I'd say that a DR is in order, because that's not what it
> says in the above sentence.

I posted a defect report titled

Defect Report: Copy-initialization in brace-enclosed initializer lists

to this newsgroup.

--
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 posted:

> The statement in question was
>
> T arr[1] = {};
>
> If I understand you correctly, you were saying that this was only legal
> if T has an accessible copy constructor. But this puzzles me, too -
> where does the standard say so?


Nope, there's no need for an accessible copy constructor (hence my
submitting it as a universal method for default-initialising an object).

    class MyClass {
    public:

        MyClass() {}

    private:

        MyClass(MyClass const&);
    };

    int main()
    {
        MyClass arr[1] = {};
    }

--

Frederick Gotham

---
[ 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                      ]

Frederick Gotham wrote:
> kanze posted:
>
> > According to    8.5.1/7: "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."  So
> >     T arr[1] = {} ;
> > is the equivalent of:
> >     T arr[1] = { T() } ;
> > which is the equivalent of:
> >     T arr = T() ;
>
>
> I don't think you're corrected there. Just because something is default-
> initialised, doesn't mean there's a copy-construction involved.

That's correct, but it misses the point. Re-read his post. It isn't the
default-initialization that determines this, it's the use of
brace-enclosed initializer list - per 8.5/12, his citation of which
you've cut out of your reply. You need an argument to justify ignoring
8.5/12. I haven't seen one.


---
[ 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                      ]

Uzytkownik "mark" <markw65@gmail.com> napisal w wiadomosci=20
news:1156268598.859412.18650@m73g2000cwd.googlegroups.com...
> "K=F8i=B9tof =AEelechovski" wrote:
>> U=BFytkownik ""Matthias Hofmann"" <hofmann@anvil-soft.com> napisa=B3 w
>> wiadomo=B6ci news:4kthd2Fdi0ouU1@individual.net...
>> >> If the precondition can never be met, the statement is trivially tr=
ue.
>> >
>> > Why?
>> >
>>
>> I do not know why.  Ask Aristotle.  It may be motivated by deontic log=
ic.
>
> You should read what you were replying to. Particularly when someone
> questions your logic.

I did and I did not find any other condition in that particular message. =
 I=20
do not memorize all posts in the thread as I read - I am not a 7-Zark-7 (=
G=20
Force, anyone?).  Sorry for this misunderstanding.

Chris=20


---
[ 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                      ]

<kuyper@wizard.net> schrieb im Newsbeitrag=20
news:1156523477.644185.312570@i42g2000cwa.googlegroups.com...
> Frederick Gotham wrote:
>> kanze posted:
>>
>> > According to =A78.5.1/7: "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."  So
>> >     T arr[1] =3D {} ;
>> > is the equivalent of:
>> >     T arr[1] =3D { T() } ;
>> > which is the equivalent of:
>> >     T arr =3D T() ;
>>
>>
>> I don't think you're corrected there. Just because something is defaul=
t-
>> initialised, doesn't mean there's a copy-construction involved.
>
> That's correct, but it misses the point. Re-read his post. It isn't the
> default-initialization that determines this, it's the use of
> brace-enclosed initializer list - per 8.5/12, his citation of which
> you've cut out of your reply. You need an argument to justify ignoring
> 8.5/12. I haven't seen one.

The argument is that in the expression

T arr[1] =3D {};

there are fewer initializers in the list than there are members in the=20
aggregate. Therefore, each member not explicitly initialized shall be=20
default-initialized. And default initialization is not copy initializatio=
n.

What we are discussing here is whether in

T arr[1] =3D {};

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

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

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

If we read 8.5.1/7 again, it says that "EACH MEMBER NOT EXPLICITLY=20
INITIALIZED shall be default-initialized". Now which is the member not=20
explicitly initialized? 'arr[0]' or the temporary (which I doubt exists a=
t=20
all)?

--=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                      ]

Matthias Hofmann wrote:
> <kuyper@wizard.net> schrieb im Newsbeitrag
> news:1156523477.644185.312570@i42g2000cwa.googlegroups.com...
> [...regarding aggregate initialization...]
>
> The argument is that in the expression
>
> T arr[1] = {};
>
> there are fewer initializers in the list than there are members in the
> aggregate. Therefore, each member not explicitly initialized shall be
> default-initialized. And default initialization is not copy initialization.
>
> What we are discussing here 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 there is no temporary created, and the object that is default
> initialized is 'arr[0]' rather than a temporary.
>
> If we read 8.5.1/7 again, it says that "EACH MEMBER NOT EXPLICITLY
> INITIALIZED shall be default-initialized". Now which is the member not
> explicitly initialized? 'arr[0]' or the temporary (which I doubt exists at
> all)?

Is that written in the '03 standard?

The newest public draft says [8.5.1/7]: "If there are fewer initializers
in the list than there are members in the aggregate, then each memeber
not explicitly initialized shall be _value-initialized_ (8.5)".

Also, it never uses the term "member of an initializer-list" (that would
be an "initializer"). It is a member of the aggregate that gets
value-initialized, and so the copy constructor is unnessesary.

Comeau compiles the following code without errors (as it should).

struct noncopyable
{
     noncopyable() {}

private:
     noncopyable(const noncopyable &);
};

struct aggregate
{
     noncopyable x;
};

int main()
{
     aggregate a = {};
}

--
Martin

---
[ 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                      ]

Frederick Gotham wrote:
> kanze posted:

> > According to    8.5.1/7: "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."  So
> >     T arr[1] = {} ;
> > is the equivalent of:
> >     T arr[1] = { T() } ;
> > which is the equivalent of:
> >     T arr = T() ;

> I don't think you're corrected there. Just because something
> is default-initialised, doesn't mean there's a
> copy-construction involved.

The copy constructor isn't involved because of default
initialization.  It's involved because "The initialization that
occurs in [...] and brace-enclosed initializer lists is called
copy-initialization, and is equivalent to the form T x = a;".

You're right, however, that default-initialization isn't
(normally) copy initialization.  Perhaps the intent is that only
explicit initializers in the list are copy initialization.  If
so, I'd say that a DR is in order, because that's not what it
says in the above sentence.

> For instance:

>     struct MyClass {
>         ostringstream obj;

>         MyClass() : obj() {}
>     };

That's because "The initialization that occurs in [...] and base
and member initializers is called direct-initialization and is
equivalent to the form T x(a);."

Note that I already quoted the first passage in the post you are
responding to.

> The following should compile just fine on every
> implementation:

> #include <sstream>
> using std::ostringstream;

> int main()
> {
>     ostringstream arr[1] = {};
> }

I still have my doubts.  The standard very definitly says that
the initialization that occurs in brace-enclosed initializer
lists is equivalent to the form T x = a.  Which requires an
accessible copy constructor.

--
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:
> <kuyper@wizard.net> schrieb im Newsbeitrag
> news:1156523477.644185.312570@i42g2000cwa.googlegroups.com...
> > Frederick Gotham wrote:
> >> kanze posted:

> >> > According to    8.5.1/7: "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."  So
> >> >     T arr[1] = {} ;
> >> > is the equivalent of:
> >> >     T arr[1] = { T() } ;
> >> > which is the equivalent of:
> >> >     T arr = T() ;

> >> I don't think you're corrected there. Just because
> >> something is default- initialised, doesn't mean there's a
> >> copy-construction involved.

> > That's correct, but it misses the point. Re-read his post.
> > It isn't the default-initialization that determines this,
> > it's the use of brace-enclosed initializer list - per
> > 8.5/12, his citation of which you've cut out of your reply.
> > You need an argument to justify ignoring 8.5/12. I haven't
> > seen one.

> The argument is that in the expression

> T arr[1] = {};

> there are fewer initializers in the list than there are
> members in the aggregate. Therefore, each member not
> explicitly initialized shall be default-initialized. And
> default initialization is not copy initialization.

That's what    8.5.1/7 says.     8.5/12 says that the initialization
that occurs in a brace-enclosed initializer list is
copy-initialization.  I don't see anything limiting this to
those elements for which there is an explicit initializer.

I don't think that the standard is 100% clear here.

> What we are discussing here 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 there is no temporary created, and the object that
> is default initialized is 'arr[0]' rather than a temporary.

Agreed.  The problem is that the standard requires
copy-initialization, while not providing for an object to be
copied.

> If we read 8.5.1/7 again, it says that "EACH MEMBER NOT
> EXPLICITLY INITIALIZED shall be default-initialized". Now
> which is the member not explicitly initialized? 'arr[0]' or
> the temporary (which I doubt exists at all)?

If it existed, it has been optimized away:-).

To tell the truth, looking at both sentences, I'm not sure which
one should apply.

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

""Martin Vejn   r"" <avakar@volny.cz> schrieb im Newsbeitrag
news:ecrei5$1lo1$1@ns.felk.cvut.cz...
> Matthias Hofmann wrote:
>> <kuyper@wizard.net> schrieb im Newsbeitrag
>> news:1156523477.644185.312570@i42g2000cwa.googlegroups.com...
>> [...regarding aggregate initialization...]
>>
>> The argument is that in the expression
>>
>> T arr[1] = {};
>>
>> there are fewer initializers in the list than there are members in the
>> aggregate. Therefore, each member not explicitly initialized shall be
>> default-initialized. And default initialization is not copy
>> initialization.
>>
>> What we are discussing here 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 there is no temporary created, and the object that is default
>> initialized is 'arr[0]' rather than a temporary.
>>
>> If we read 8.5.1/7 again, it says that "EACH MEMBER NOT EXPLICITLY
>> INITIALIZED shall be default-initialized". Now which is the member not
>> explicitly initialized? 'arr[0]' or the temporary (which I doubt exists
>> at all)?
>
> Is that written in the '03 standard?

No, its in the 98 standard. I do not have a copy of the 03 draft.

> The newest public draft says [8.5.1/7]: "If there are fewer initializers
> in the list than there are members in the aggregate, then each memeber not
> explicitly initialized shall be _value-initialized_ (8.5)".

I don't know what value-initialized means - does it involve copy
construction?

> Also, it never uses the term "member of an initializer-list" (that would
> be an "initializer"). It is a member of the aggregate that gets
> value-initialized, and so the copy constructor is unnessesary.
>
> Comeau compiles the following code without errors (as it should).
>

[snipping code]

That's my point. The way I understand things, neither the new nor the old
standard requires an accessible copy constructor in an expression such as

T arr[1] = {};

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

Jens Theisen wrote:
> kanze wrote:

    [Concerning T t = T() ;]

> > It's only legal
> > if T has an accessible copy constructor,

> Why this?

Because that's what the standard says.  Basically, you're
constructing a T from an expression with type T.  And how do you
do that unless you call the copy constructor?

--
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:
> ""Kristof Zelechovski"" <giecrilj@stegny.2a.pl> schrieb im Newsbeitrag
> news:ec3l3a$239g$1@news2.ipartners.pl...
>
> >>> > . Except when forming a pointer to member (5.3.1), the access must be
> >>> > through a pointer to, reference to, or object of the derived class
> >>> > iteself (or any class derived from that class) (5.2.5).
> >>>
> >>> Yes, that's true. A protected member can be accessed only if those
> >>> conditions you mentioned are also met.
> >>
> >> And since they can never be met for the snippet in question ("X x =
> >> X();", if you remember), the statement 'If it appears inside a member
> >> of a derived class, "protected" should suffice.' is in fact false.
> >>
> >
> > If the precondition can never be met, the statement is trivially true.
>
> Why?

Because he didnt read the thread, and thought that "the conditions can
never be met" refered to "if it appears inside a member of a derived
class".

Mark Williams

---
[ 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:1156162332.681008.153540@m73g2000cwd.googlegroups.com...
> Jens Theisen wrote:
>> kanze wrote:
>
>    [Concerning T t = T() ;]
>
>> > It's only legal
>> > if T has an accessible copy constructor,
>
>> Why this?
>
> Because that's what the standard says.  Basically, you're
> constructing a T from an expression with type T.  And how do you
> do that unless you call the copy constructor?

The statement in question was

T arr[1] = {};

If I understand you correctly, you were saying that this was only legal if T
has an accessible copy constructor. But this puzzles me, too - where does
the standard say so?

--
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:
> "kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> news:1156162332.681008.153540@m73g2000cwd.googlegroups.com...
> > Jens Theisen wrote:
> >> kanze wrote:

> >    [Concerning T t = T() ;]

> >> > It's only legal
> >> > if T has an accessible copy constructor,

> >> Why this?

> > Because that's what the standard says.  Basically, you're
> > constructing a T from an expression with type T.  And how do you
> > do that unless you call the copy constructor?

> The statement in question was

> T arr[1] = {};

Sorry, I thought it was the other.  But that doesn't change
anything.  You still need an accessible copy constructor.

> If I understand you correctly, you were saying that this was
> only legal if T has an accessible copy constructor. But this
> puzzles me, too - where does the standard say so?

   8.5/12: "The initialization that occurs in [...] and
brace-enclosed initializer lists is called copy-initialization,
and is equivalent to the form  T x = a;"

According to    8.5.1/7: "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."  So
    T arr[1] = {} ;
is the equivalent of:
    T arr[1] = { T() } ;
which is the equivalent of:
    T arr = T() ;

QED

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

kanze posted:

> According to =A78.5.1/7: "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."  So
>     T arr[1] =3D {} ;
> is the equivalent of:
>     T arr[1] =3D { T() } ;
> which is the equivalent of:
>     T arr =3D T() ;


I don't think you're corrected there. Just because something is default-
initialised, doesn't mean there's a copy-construction involved. For=20
instance:

    struct MyClass {
        ostringstream obj;

        MyClass() : obj() {}
    };

The following should compile just fine on every implementation:

#include <sstream>
using std::ostringstream;

int main()
{
    ostringstream arr[1] =3D {};
}

--=20

Frederick Gotham

---
[ 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:1155833485.406514.274480@i3g2000cwc.googlegroups.com...
> Frederick Gotham wrote:
>> Thomas posted:
>
>> > I did not know that "X x = X()" did default initialize and
>> > that "X x" didn't.
>
>> > Good to Know :)
>
>> You should have learned that very early.
>
>> int main()
>> {
>>     int i; /* "i" contains white noise */
>> }
>
> As did T() if there was no user defined constructors.  Until
> somewhere during the standardization process.  I suspect that a
> lot of more experienced C++ programmers aren't aware of the
> change.

So am I - what exactly has changed, and what is the current rule for T()?

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

Uzytkownik "mark" <markw65@gmail.com> napisal w wiadomosci
news:1155845943.564948.233640@75g2000cwc.googlegroups.com...
>
> "Matthias Hofmann" wrote:
>> "mark" <markw65@gmail.com> schrieb im Newsbeitrag
>> news:1155753523.459377.147180@m79g2000cwm.googlegroups.com...
>>
>> >> >> If it appears inside a member of a derived class, "protected"
>> >> >> should
>> >> >> suffice.
>> >> >
>> >> > Really?
>> >>
>> >> Yes, see section 11/1: "A member of a class can be [...] protected;
>> >> that
>> >> is,
>> >> its name can be used only by members and friends of the class in which
>> >> it
>> >> is
>> >> declared, and by members and friends of classes derived from this
>> >> class."
>> >
>> > You left off the important part of the sentence (see 11.5), which says:
>> >
>> > . Except when forming a pointer to member (5.3.1), the access must be
>> > through a pointer to, reference to, or object of the derived class
>> > iteself (or any class derived from that class) (5.2.5).
>>
>> Yes, that's true. A protected member can be accessed only if those
>> conditions you mentioned are also met.
>
> And since they can never be met for the snippet in question ("X x =
> X();", if you remember), the statement 'If it appears inside a member
> of a derived class, "protected" should suffice.' is in fact false.
>

If the precondition can never be met, the statement is trivially true.
Chris



---
[ 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:
> "kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> news:1155833485.406514.274480@i3g2000cwc.googlegroups.com...
> > Frederick Gotham wrote:
> >> Thomas posted:

> >> > I did not know that "X x = X()" did default initialize and
> >> > that "X x" didn't.

> >> > Good to Know :)

> >> You should have learned that very early.

> >> int main()
> >> {
> >>     int i; /* "i" contains white noise */
> >> }

> > As did T() if there was no user defined constructors.  Until
> > somewhere during the standardization process.  I suspect
> > that a lot of more experienced C++ programmers aren't aware
> > of the change.

> So am I - what exactly has changed, and what is the current
> rule for T()?

>From    8.5/7: "An object whose initializer is an empty set of
parentheses, i.e., (), shall be default-initialized."  Paragraph
5 defines default-initialize; it is basically what happens (and
had always happened) if the variable is defined with static
lifetime.

IIRC, this was added relatively late in the previous
standardization process.  After people started getting some real
experience with templates, and realized that it might be a good
idea to have a standard syntax for ensuring some initialization.

Note that for a non-POD class type, the default constructor for
T is called.  In the unlikely case that you define a
user-defined destructor or a user-defined copy assignment
operator, but no constructor, T() becomes once again a no-op (or
rather, leaves the object in an undefined state).

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

"Kristof Zelechovski" wrote:
> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
> news:1155833275.678725.297060@h48g2000cwc.googlegroups.com...
> > K   i   tof    elechovski wrote:

> >> T t = T(0, &t);    // error: copy constructor is private.

> >> I complained to Microsoft about the first line but they said
> >> they do not support C99 and closed the case.

> > What does that have to do with C99?   Are you sure you aren't
> > mixing up two different issues.  Even a Microsoft customer
> > support engineer should be aware that C (99 or otherwise)
> > doesn't have classes, nor public and private, nor constructors.

> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99098

Where they say that they cannot fix it because they are too
close to release.  There's also an off hand comment concerning
C99, but it doesn't seem to have anything to do with this bug
report (or anything else that I can see, for that matter).

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

""Kristof Zelechovski"" <giecrilj@stegny.2a.pl> schrieb im Newsbeitrag
news:ec3l3a$239g$1@news2.ipartners.pl...

>>> > . Except when forming a pointer to member (5.3.1), the access must be
>>> > through a pointer to, reference to, or object of the derived class
>>> > iteself (or any class derived from that class) (5.2.5).
>>>
>>> Yes, that's true. A protected member can be accessed only if those
>>> conditions you mentioned are also met.
>>
>> And since they can never be met for the snippet in question ("X x =
>> X();", if you remember), the statement 'If it appears inside a member
>> of a derived class, "protected" should suffice.' is in fact false.
>>
>
> If the precondition can never be met, the statement is trivially true.

Why?

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

"kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
news:1156163006.926218.91070@i3g2000cwc.googlegroups.com...

> Note that for a non-POD class type, the default constructor for
> T is called.  In the unlikely case that you define a
> user-defined destructor or a user-defined copy assignment
> operator, but no constructor, T() becomes once again a no-op (or
> rather, leaves the object in an undefined state).

I thought that a user-defined destructor would not have any influence on the
implicit definition of a default constructor, but the following code does
indeed output a random value:

struct X
{
    ~X() {}

    int i;
};

int main()
{
    cout << X().i << endl;

    return 0;
}

This puzzles me, as it does not seem to make any sense. Can you please show
me the sections of the standard that require this behaviour?

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

U=BFytkownik ""Matthias Hofmann"" <hofmann@anvil-soft.com> napisa=B3 w=20
wiadomo=B6ci news:4kthd2Fdi0ouU1@individual.net...
>> If the precondition can never be met, the statement is trivially true.
>
> Why?
>

I do not know why.  Ask Aristotle.  It may be motivated by deontic logic.
Chris=20



---
[ 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:
> "kanze" <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> news:1156163006.926218.91070@i3g2000cwc.googlegroups.com...

> > Note that for a non-POD class type, the default constructor
> > for T is called.  In the unlikely case that you define a
> > user-defined destructor or a user-defined copy assignment
> > operator, but no constructor, T() becomes once again a no-op
> > (or rather, leaves the object in an undefined state).

> I thought that a user-defined destructor would not have any
> influence on the implicit definition of a default constructor,

It doesn't, but it prevents the type from being a POD.  And the
definition of default construction for a non-POD is NOT zero
initialization, but calling the (here, compiler generated)
default constructor.

> but the following code does
> indeed output a random value:

> struct X
> {
>     ~X() {}
>     int i;
> };

> int main()
> {
>     cout << X().i << endl;
>     return 0;
> }

> This puzzles me, as it does not seem to make any sense. Can
> you please show me the sections of the standard that require
> this behaviour?

Well, nothing requires the value to be random:-).  But the fact
that zero initialization doesn't occur is due to the first
bullet in the second list of    8.5/5: "To default-initialize an
object of type T means: -- if T is a non-POD class (clause 9),
the default constructor for T is called [...]"  And we don't get
to the third bullet, "otherwise, the storage for the object is
zero-initialized".  The presence of a non-trival destructor
means that the type is not a POD, thus, it is a non-POD class
type.  (Note that the same thing is true if the class has a
virtual function.)

In practice, although surprising, I don't think it matters.  I
can't think of a case where I would have a user defined
destructor, and no user-defined constructors.  And of course, as
soon as I have a user-defined constructor, the compiler
generated default constructor disappears, and it's up to me to
do whatever is needed.

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

"K   i   tof    elechovski" wrote:
> U   ytkownik ""Matthias Hofmann"" <hofmann@anvil-soft.com> napisa    w
> wiadomo   ci news:4kthd2Fdi0ouU1@individual.net...
> >> If the precondition can never be met, the statement is trivially true.
> >
> > Why?
> >
>
> I do not know why.  Ask Aristotle.  It may be motivated by deontic logic.

You should read what you were replying to. Particularly when someone
questions your logic.

The precondition of the statement can easily be met. Its just the
conditions which make the statement true that cannot. Aristotle has
nothing to do with it.

Mark Williams


---
[ 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                      ]

K   i   tof    elechovski wrote:
> U   ytkownik ""Matthias Hofmann"" <hofmann@anvil-soft.com> napisa    w
> wiadomo   ci news:4kebv5Fbjid9U3@individual.net...
> > "Frederick Gotham" <fgothamNO@SPAM.com> schrieb im Newsbeitrag
> > news:hPkEg.12700$j7.324766@news.indigo.ie...

> >> There are better ways to achieve what you want. Here's my
> >> own particular favourite way of default-initialising an
> >> object:

> >> template<class T>
> >> void Func()
> >> {
> >>    T arr[1] = {};

> >>    T &obj = *arr;
> >>
> >>    /* Now work with "obj" */
> >> }

> > This looks rather strange. How does it exactly work? What's
> > the deal with those curly brackets?

More than strange, it's unnecessarily verbvse.  It's only legal
if T has an accessible copy constructor, in which case, you can
just as easily write:

    T obj = T() ;

> C++ is schizophrenic when it comes to default initialization.
> If you write T t = T(), you run into the problem of
> inaccessible copy constructor.  If you write T t, you will get
> uninitialized variables for built-in types.  Those curly
> brackets work for both cases.

It depends.

If the class has an inaccessible copy constructor, it either has
a user defined default constructor, and simply writing:
    T obj ;
is sufficient; the user defined default constructor will do
whatever T() or the braces initialization would do.  Or there is
NO default constructor, and no way to construct an object
without providing some arguments.

> There is, however, a case that will not work, at least not for
> Visual C++ 14.  Here it goes:

> class T { public: T(int, T *); private: T(T const &); };

> T t(0, &t);    // error: t: unknown identifier

That's a definite error in the compiler.  The standard is quite
clear.  The point of declaration is before the initializer (see
   3.3.1/1).  There are a few exceptions, but none which apply
here.

It's an easy error to make.  You have to parse a good deal ahead
before you can determine that you are dealing with an
initializer.  With a little ingenuity, I'll bet you can
construct cases which would fool any compiler.  Basically, the
compiler has to parse the contents of the parentheses before it
can know whether it is dealing with an initializer or a function
parameter list (in which case, the point of declaration comes
after).  And of course, it's something exotic enough and rare
enough that it's unlikely that the in house tests will catch it,
unless the error has been reported before.

> T t = T(0, &t);    // error: copy constructor is private.

> I complained to Microsoft about the first line but they said
> they do not support C99 and closed the case.

What does that have to do with C99?   Are you sure you aren't
mixing up two different issues.  Even a Microsoft customer
support engineer should be aware that C (99 or otherwise)
doesn't have classes, nor public and private, nor constructors.

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

Frederick Gotham wrote:
> Thomas posted:

> > I did not know that "X x = X()" did default initialize and
> > that "X x" didn't.

> > Good to Know :)

> You should have learned that very early.

> int main()
> {
>     int i; /* "i" contains white noise */
> }

As did T() if there was no user defined constructors.  Until
somewhere during the standardization process.  I suspect that a
lot of more experienced C++ programmers aren't aware of the
change.

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

"mark" <markw65@gmail.com> schrieb im Newsbeitrag
news:1155753523.459377.147180@m79g2000cwm.googlegroups.com...

>> >> If it appears inside a member of a derived class, "protected" should
>> >> suffice.
>> >
>> > Really?
>>
>> Yes, see section 11/1: "A member of a class can be [...] protected; that
>> is,
>> its name can be used only by members and friends of the class in which it
>> is
>> declared, and by members and friends of classes derived from this class."
>
> You left off the important part of the sentence (see 11.5), which says:
>
> . Except when forming a pointer to member (5.3.1), the access must be
> through a pointer to, reference to, or object of the derived class
> iteself (or any class derived from that class) (5.2.5).

Yes, that's true. A protected member can be accessed only if those
conditions you mentioned are also met.

--
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:
> "mark" <markw65@gmail.com> schrieb im Newsbeitrag
> news:1155753523.459377.147180@m79g2000cwm.googlegroups.com...
>
> >> >> If it appears inside a member of a derived class, "protected" should
> >> >> suffice.
> >> >
> >> > Really?
> >>
> >> Yes, see section 11/1: "A member of a class can be [...] protected; that
> >> is,
> >> its name can be used only by members and friends of the class in which it
> >> is
> >> declared, and by members and friends of classes derived from this class."
> >
> > You left off the important part of the sentence (see 11.5), which says:
> >
> > . Except when forming a pointer to member (5.3.1), the access must be
> > through a pointer to, reference to, or object of the derived class
> > iteself (or any class derived from that class) (5.2.5).
>
> Yes, that's true. A protected member can be accessed only if those
> conditions you mentioned are also met.

And since they can never be met for the snippet in question ("X x =
X();", if you remember), the statement 'If it appears inside a member
of a derived class, "protected" should suffice.' is in fact false.

Mark Williams

Mark Williams

---
[ 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                      ]

"mark" <markw65@gmail.com> schrieb im Newsbeitrag
news:1155845943.564948.233640@75g2000cwc.googlegroups.com...
>
> "Matthias Hofmann" wrote:
>> "mark" <markw65@gmail.com> schrieb im Newsbeitrag
>> news:1155753523.459377.147180@m79g2000cwm.googlegroups.com...
>>
>> >> >> If it appears inside a member of a derived class, "protected"
>> >> >> should
>> >> >> suffice.
>> >> >
>> >> > Really?
>> >>
>> >> Yes, see section 11/1: "A member of a class can be [...] protected;
>> >> that
>> >> is,
>> >> its name can be used only by members and friends of the class in which
>> >> it
>> >> is
>> >> declared, and by members and friends of classes derived from this
>> >> class."
>> >
>> > You left off the important part of the sentence (see 11.5), which says:
>> >
>> > . Except when forming a pointer to member (5.3.1), the access must be
>> > through a pointer to, reference to, or object of the derived class
>> > iteself (or any class derived from that class) (5.2.5).
>>
>> Yes, that's true. A protected member can be accessed only if those
>> conditions you mentioned are also met.
>
> And since they can never be met for the snippet in question ("X x =
> X();", if you remember), the statement 'If it appears inside a member
> of a derived class, "protected" should suffice.' is in fact false.

It looks like you are right, and I remember that this has been discussed
before. I checked the standard again and tried it on my compiler: there
seems to be no way for a friend or member function of a derived class to
invoke the protected copy constructor of a base class.

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

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci=20
news:1155833275.678725.297060@h48g2000cwc.googlegroups.com...
> K=F8i=B9tof =AEelechovski wrote:

>> T t =3D T(0, &t);    // error: copy constructor is private.
>
>> I complained to Microsoft about the first line but they said
>> they do not support C99 and closed the case.
>
> What does that have to do with C99?   Are you sure you aren't
> mixing up two different issues.  Even a Microsoft customer
> support engineer should be aware that C (99 or otherwise)
> doesn't have classes, nor public and private, nor constructors.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feed=
backID=3D99098




---
[ 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 wrote:

> It's only legal
> if T has an accessible copy constructor,

Why this?

Jens

---
[ 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                      ]

"Frederick Gotham" <fgothamNO@SPAM.com> schrieb im Newsbeitrag
news:hPkEg.12700$j7.324766@news.indigo.ie...

> There are better ways to achieve what you want. Here's my own particular
> favourite way of default-initialising an object:
>
> template<class T>
> void Func()
> {
>    T arr[1] = {};
>
>    T &obj = *arr;
>
>    /* Now work with "obj" */
> }

This looks rather strange. How does it exactly work? What's the deal with
those curly brackets?

--
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" posted:

>> template<class T>
>> void Func()
>> {
>>    T arr[1] = {};
>>
>>    T &obj = *arr;
>>
>>    /* Now work with "obj" */
>> }
>
> This looks rather strange. How does it exactly work? What's the deal with
> those curly brackets?


Here's how you default-initialise every element of an array:

    int array[5] = {};

This works with every type. I use it with an array of length 1:

    int array[1] = {};

, so the sole element gets default-initialised. I then create a reference
to the first element:

    int array[1] = {};

    int &i = *array;

--

Frederick Gotham

---
[ 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 2006-08-15 13:07:58 -0400, hofmann@anvil-soft.com ("Matthias Hofmann") said:

> "Frederick Gotham" <fgothamNO@SPAM.com> schrieb im Newsbeitrag
> news:hPkEg.12700$j7.324766@news.indigo.ie...
>
>> There are better ways to achieve what you want. Here's my own particular
>> favourite way of default-initialising an object:
>>
>> template<class T>
>> void Func()
>> {
>> T arr[1] = {};
>>
>> T &obj = *arr;
>>
>> /* Now work with "obj" */
>> }
>
> This looks rather strange. How does it exactly work? What's the deal
> with those curly brackets?

//This line creates an array containing a single default-initialized T object
T arr[1] = {};

//obj now refers to that same object
T &obj = *arr;

This will work in cases where the following won't:
T obj = T(); //Won't work with types without a visible copy constructor
T obj; //Won't initialize built-in types

--
Clark S. Cox, III
clarkcox3@gmail.com

---
[ 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                      ]

Thank you!

I did not know that "X x = X()" did default initialize and that "X x"
didn't.

Good to Know :)

---
[ 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                      ]

"Victor Bazarov" wrote:
> Shouldn't this be moved to a .lang. newsgroup?  Just checking...
>
> Frederick Gotham wrote:
> > Thomas posted:
> >
> >> Hello fellow programmers!
> >>
> >> I have a c++ line:
> >>
> >> X x = X();
> >>
> >> Does the standard say that the class X must have a public copy
> >> constructor for this to be legal, even if the copy constructor never
> >> gets called?
> >
> >
> > Yes, although it gives explicit permission to the compiler to elide
> > the creation of the redudant temporary object. Even if the temporary
> > is elided, the copy-constructor must still be public.
>
> Not "public", *accessible*.  If the "c++ line" above appears inside
> a friend function, it would work just fine with a private copy c-tor.

Yes.

> If it appears inside a member of a derived class, "protected" should
> suffice.

Really?

Mark Williams

---
[ 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                      ]

U   ytkownik ""Matthias Hofmann"" <hofmann@anvil-soft.com> napisa    w
wiadomo   ci news:4kebv5Fbjid9U3@individual.net...
> "Frederick Gotham" <fgothamNO@SPAM.com> schrieb im Newsbeitrag
> news:hPkEg.12700$j7.324766@news.indigo.ie...
>
>> There are better ways to achieve what you want. Here's my own particular
>> favourite way of default-initialising an object:
>>
>> template<class T>
>> void Func()
>> {
>>    T arr[1] = {};
>>
>>    T &obj = *arr;
>>
>>    /* Now work with "obj" */
>> }
>
> This looks rather strange. How does it exactly work? What's the deal with
> those curly brackets?

C++ is schizophrenic when it comes to default initialization.  If you write
T t = T(), you run into the problem of inaccessible copy constructor.  If
you write T t, you will get uninitialized variables for built-in types.
Those curly brackets work for both cases.

There is, however, a case that will not work, at least not for Visual C++
14.  Here it goes:

class T { public: T(int, T *); private: T(T const &); };

T t(0, &t);    // error: t: unknown identifier
T t = T(0, &t);    // error: copy constructor is private.

I complained to Microsoft about the first line but they said they do not
support C99 and closed the case.

Chris

Chris



---
[ 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                      ]

"mark" <markw65@gmail.com> schrieb im Newsbeitrag
news:1155663179.843769.44420@b28g2000cwb.googlegroups.com...
>
> "Victor Bazarov" wrote:
>> Shouldn't this be moved to a .lang. newsgroup?  Just checking...
>>
>> Frederick Gotham wrote:
>> > Thomas posted:
>> >
>> >> Hello fellow programmers!
>> >>
>> >> I have a c++ line:
>> >>
>> >> X x = X();
>> >>
>> >> Does the standard say that the class X must have a public copy
>> >> constructor for this to be legal, even if the copy constructor never
>> >> gets called?
>> >
>> >
>> > Yes, although it gives explicit permission to the compiler to elide
>> > the creation of the redudant temporary object. Even if the temporary
>> > is elided, the copy-constructor must still be public.
>>
>> Not "public", *accessible*.  If the "c++ line" above appears inside
>> a friend function, it would work just fine with a private copy c-tor.
>
> Yes.
>
>> If it appears inside a member of a derived class, "protected" should
>> suffice.
>
> Really?

Yes, see section 11/1: "A member of a class can be [...] protected; that is,
its name can be used only by members and friends of the class in which it is
declared, and by members and friends of classes derived from this class."

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

K   i   tof    elechovski wrote:
[...]
> C++ is schizophrenic when it comes to default initialization.  If you write
> T t = T(), you run into the problem of inaccessible copy constructor.  If
> you write T t, you will get uninitialized variables for built-in types.

..not to mention that if you write T t() you are declaring a function.

Cheers,
Nicola Musatti


---
[ 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                      ]

Thomas posted:

> Thank you!
>
> I did not know that "X x = X()" did default initialize and that "X x"
> didn't.
>
> Good to Know :)


You should have learned that very early.

int main()
{
    int i; /* "i" contains white noise */
}

--

Frederick Gotham

---
[ 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:
> "mark" <markw65@gmail.com> schrieb im Newsbeitrag
> news:1155663179.843769.44420@b28g2000cwb.googlegroups.com...
> >
> > "Victor Bazarov" wrote:
> >> Shouldn't this be moved to a .lang. newsgroup?  Just checking...
> >>
> >> Frederick Gotham wrote:
> >> > Thomas posted:
> >> >
> >> >> Hello fellow programmers!
> >> >>
> >> >> I have a c++ line:
> >> >>
> >> >> X x = X();
> >> >>
> >> >> Does the standard say that the class X must have a public copy
> >> >> constructor for this to be legal, even if the copy constructor never
> >> >> gets called?
> >> >
> >> >
> >> > Yes, although it gives explicit permission to the compiler to elide
> >> > the creation of the redudant temporary object. Even if the temporary
> >> > is elided, the copy-constructor must still be public.
> >>
> >> Not "public", *accessible*.  If the "c++ line" above appears inside
> >> a friend function, it would work just fine with a private copy c-tor.
> >
> > Yes.
> >
> >> If it appears inside a member of a derived class, "protected" should
> >> suffice.
> >
> > Really?
>
> Yes, see section 11/1: "A member of a class can be [...] protected; that is,
> its name can be used only by members and friends of the class in which it is
> declared, and by members and friends of classes derived from this class."

You left off the important part of the sentence (see 11.5), which says:

. Except when forming a pointer to member (5.3.1), the access must be
through a pointer to, reference to, or object of the derived class
iteself (or any class derived from that class) (5.2.5).

Mark Williams

---
[ 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                      ]

Hello fellow programmers!

I have a c++ line:

X x = X();

Does the standard say that the class X must have a public copy
constructor for this to be legal, even if the copy constructor never
gets called?

I have experimented with this, and if X's copy constructor is pivate
the compilation fails, but when I run this, with a public copy
constructor, the copy constructor never gets called. So is this legal
for the optimizer, or whatever, to optimize this copy constructor away,
and just create code like I've writen "X x;" ? But the compiler can not
approve the code if it wants to conform to the standard?

If I am right, can anyone explain why it is so?

-Thomas

---
[ 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                      ]

Thomas posted:

> Hello fellow programmers!
>
> I have a c++ line:
>
> X x = X();
>
> Does the standard say that the class X must have a public copy
> constructor for this to be legal, even if the copy constructor never
> gets called?


Yes, although it gives explicit permission to the compiler to elide the
creation of the redudant temporary object. Even if the temporary is elided,
the copy-constructor must still be public.


> I have experimented with this, and if X's copy constructor is pivate
> the compilation fails, but when I run this, with a public copy
> constructor, the copy constructor never gets called.


Same as on most systems.


> So is this legal for the optimizer, or whatever, to optimize this copy
> constructor away, and just create code like I've writen "X x;" ?


Yes. Even if no temporary is created, the following two definitions are
*not* equivalent if you're working with a type which hasn't got a
constructor:

    X x = X();  /* Get's default-initialised */

    X x; /* Doesn't get initialised unless there's a constructor */


> But the compiler can not approve the code if it wants to conform to the
> standard?


No it can't.


> If I am right, can anyone explain why it is so?


There are better ways to achieve what you want. Here's my own particular
favourite way of default-initialising an object:

template<class T>
void Func()
{
    T arr[1] = {};

    T &obj = *arr;

    /* Now work with "obj" */
}

--

Frederick Gotham

---
[ 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                      ]

Shouldn't this be moved to a .lang. newsgroup?  Just checking...

Frederick Gotham wrote:
> Thomas posted:
>
>> Hello fellow programmers!
>>
>> I have a c++ line:
>>
>> X x = X();
>>
>> Does the standard say that the class X must have a public copy
>> constructor for this to be legal, even if the copy constructor never
>> gets called?
>
>
> Yes, although it gives explicit permission to the compiler to elide
> the creation of the redudant temporary object. Even if the temporary
> is elided, the copy-constructor must still be public.

Not "public", *accessible*.  If the "c++ line" above appears inside
a friend function, it would work just fine with a private copy c-tor.
If it appears inside a member of a derived class, "protected" should
suffice.

>> So is this legal for the optimizer, or whatever, to optimize this
>> copy constructor away, and just create code like I've writen "X x;" ?
>
>
> Yes. Even if no temporary is created, the following two definitions
> are *not* equivalent if you're working with a type which hasn't got a
> constructor:
>
>    X x = X();  /* Get's default-initialised */
>
>    X x; /* Doesn't get initialised unless there's a constructor */

That depends on whether 'X' is a POD or not.  If it's not a POD but it
doesn't have a [user-defined] constructor, but all it members have them,
it is going to be default-initialised just fine.

>> If I am right, can anyone explain why it is so?
>
>
> There are better ways to achieve what you want. Here's my own
> particular favourite way of default-initialising an object:
>
> template<class T>
> void Func()
> {
>    T arr[1] = {};
>
>    T &obj = *arr;
>
>    /* Now work with "obj" */
> }

To OP: you don't have to use templates to do what you want.  Apply the
same technique and just replace 'T' with 'X'.  BTW, you can write this
in the same line, AFAIK:

    X arr_[2] = {}, &x = arr_[0], &xx = arr_[1]; // two objects

and by utilizing some preprocessor magic, you can make up unique names
for the arrays (if there are several such lines in your scope).  I'll
leave that exercise to the reader.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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                      ]