"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote in message
news:slrna0ah2l.pp.qrczak@qrnik.zagroda...
> Wed, 28 Nov 2001 19:03:54 GMT, Ron Natalie <ron@sensor.com> pisze:
>
> > It's really:
> > A a(A(12))
> >
> > If you don't have a usable copy constructor, or the conversion of int->
> > A is thwarted (like you make the A(int) constructor explicit), it is
> > ill formed.
>
> So it's not really A a(A(12)) which is valid when A(int) is explicit.

I guess it's more like

A a(static_cast<A>(12));

then.  In view of this, I'm glad I have the "A a=12" alternative for this
long notation, as I can always type "A a(12)" if that's what I really want.
The subtleties can have significant ramifications when doing generic
programming for (supposedly) mathematical types.

For instance, I have a Matrix template class that I can instance for any
algebraic object.  If someone tries to use a stl vector in my Matrix
template, it's nice to know that when I try to initialize my T (where T is
std::vector<something>) to have a mathematical value of 1, I will get a
diagnostic instead of a quiet vector of length 1 (and no mathematical "1"
value at all).


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ren=E9 van Oostrum" wrote:
[...]
> I don't see the problem; if you don't like the fact that you have to
> write an accessible copy constructor to make 'A a =3D 12;' valid, then
> why don't you simply write 'A a(12);' in the first place? It is
> shorter, clearer (IMO), it works regardless of the accessibility of
> the copy constructor, and regardless the explicitness of the
> constructor.

Clearer? How about:

class A { /* ... */ };
class B { /* ... */ };

A f(B());

What is f?

I don't have my copy of D&E at hand, so I'm not sure about the rationale
for introducing the function-style initialization syntax; but given that

A f =3D B(); // (1)

is already interpreted differently from

f =3D B(); // (2)

I wonder why wasn't (1) defined as a simple call to A(B) rather than
introducing a potential source of problems as function style
initialization. Given that you can't rely on the copy construction being
really performed in (1) the existence of both syntaxes appears useless.
Am I missing anything?

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.research.att.com/~austern/csc/faq.html                ]

> Daniel Frey wrote:
> >
> > thus the copy-ctor must be accessible. I simply can't believe that this
> > is true as it looks brain-damaged to me.
> The reason is that
>
> A a=A(12);  // i.e. A a(A(12));
>
> It seems to be inefficient (and it is) but compiler is allowed to
eliminate
> _temporary_ objects (try to explain this to Francis :) so on the most
> implementations you'll get your A a(12);

I would competly disagree with the statement

> >   A a = 12;
> >
> > is identical to:
> >
> >   A a(A(12));

if you have the class

class A
{
    A(int);
.....
}

then the statment

A a = 12

is not an assignment. It's a call to the construtor and is equivelent to.

A a(12); // the call A(int)

A temp copy is not made and the copy construtor is not called


Garth



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Garth
> if you have the class
>
> class A
> {
>     A(int);
> .....
> }
>
> then the statment
>
> A a = 12
>
> is not an assignment. It's a call to the construtor and is equivelent to.
>
> A a(12); // the call A(int)
>
> A temp copy is not made and the copy construtor is not called

It's not an assignement, but it is neither a call to the constructor
nor is it equivelent to A a(12).  A copy is logically made, although
the compiler is free to optimize it away.  However, even if it optimizes
it away, the mechanisms (both the copy constructor and the conversion
from int->A) must exist and be accessible (i.e., the fact that the
temporary is elided or not has no bearing on the whether the program
is well forme).

It's really:
 A a(A(12))

If you don't have a usable copy constructor, or the conversion of int->
A is thwarted (like you make the A(int) constructor explicit), it is
ill formed.

This is back where we started.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Wed, 28 Nov 2001 19:03:54 GMT, Ron Natalie <ron@sensor.com> pisze:

> It's really:
>  A a(A(12))
>
> If you don't have a usable copy constructor, or the conversion of int->
> A is thwarted (like you make the A(int) constructor explicit), it is
> ill formed.

So it's not really A a(A(12)) which is valid when A(int) is explicit.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Marcin 'Qrczak' Kowalczyk wrote:
>=20
> So it's not really A a(A(12)) which is valid when A(int) is explicit.

Which is why I don't consider it more consistent than 'A a =3D 12;' being
declared as 'A a(12);', as explicit ctors are the same exception for
both cases. Still I don't really understand the reason for the
definition like it is :(

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Daniel Frey wrote:
>
> Hi,
>
> in comp.lang.c++ I was told that given a class A with A::A(int)
>
>   A a = 12;
>
> is identical to:
>
>   A a(A(12));
>
> thus the copy-ctor must be accessible. I simply can't believe that this
> is true as it looks brain-damaged to me.

Pretty much.  It works out this way in this case.  However, the rule is
that the thing to the right of the equal sign is converted somehow to
type A and that is used to copy initialize A.  Now in the case of the
intializer being int and A having a converting constructor for int,
what you wrote is what happens.

Of course, if the initializer was some other type, there might be a way
to convert from it to type A other than using A's converting constructor.

It wouldn't be very consistanct to require a copy constructor for other
conversions but not when there your special case.

Of course, the compiler is free to elide the copy, but the copy constructor
still has to be checked to see that it would be usuable.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3BFB70B5.F9174A2A@aixigo.de>, Daniel Frey
<daniel.frey@aixigo.de> writes
>Hi,
>
>in comp.lang.c++ I was told that given a class A with A::A(int)
>
>  A a = 12;
>
>is identical to:
>
>  A a(A(12));
>
>thus the copy-ctor must be accessible. I simply can't believe that this
>is true as it looks brain-damaged to me. Can anyone please tell me that
>the folks at clc++ are either simply wrong or that there is some damn
>good reason for the standard to require the above behaviour instead of
>declaring 'A a = 12' is the same than 'A a(12)' except for 'explicit
>ctor's'? Help... :))

Yes, it does look silly in the example you give, but the rules have to
work correctly in other cases and we do not want a whole bundle of
special cases (they are very hard to write correctly)

Suppose that I have

void foo(A);

Do you think foo(12) should always work even if the designer of A has
carefully made A(int) explicit, i.e. no implicit conversions? You do?
Sure? Then how about:

A operator+(A, A);
A a(12);
a = a+12;
And so on. We give the class designer power to limit implicit
conversions and copying, one small consequence of that is that

A a = 12;

is equivalent to

A a(A(12));

Not only when it is written explicitly but in all the other less obvious
cases where a declaration is used (particularly for parameters)



--
Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:

> We give the class designer power to limit implicit=20
> conversions and copying, one small consequence of that is that
>=20
> A a =3D 12;
>=20
> is equivalent to
>=20
> A a(A(12));
>=20
> Not only when it is written explicitly but in all the other less obviou=
s
> cases where a declaration is used (particularly for parameters)

AFAICT there was no a priori reason that requires

  A a =3D 12;

to be considered as copy initialization (rather than direct
initialization). It could have been specified that an initializer of the
form=20

  =3D <expression>

is simply equivalent to the corresponding initializer of the form

  (<expression>)

This would not have precluded defining copy-initialization as it is now
and to use it for implicit initializations (e.g. of function arguments
and return values).

A different decision was taken on this, but in some cases it has
unpleasant or unexpected consequences.=20

For example I just recently met the problem that an object must have an
accessible copy constructor to be declared in a condition.

Regards, J=F6rg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://util.openoffice.org
StarOffice Configuration      =3D Jetzt erh=E4ltlich:StarOffice 6 Beta

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Daniel Frey wrote:
>   A a = 12;
>
> is identical to:
>
>   A a(A(12));
>
> thus the copy-ctor must be accessible. I simply can't believe that this
> is true as it looks brain-damaged to me.
The reason is that

 T t=...;

is initialization. I.e. we create a t from a T. And there is no A in "=
12;" so we have to create it:

 A a=A(12);  // i.e. A a(A(12));

It seems to be inefficient (and it is) but compiler is allowed to eliminate
_temporary_ objects (try to explain this to Francis :) so on the most
implementations you'll get your A a(12);
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Joerg Barfurth wrote:
[...]
> AFAICT there was no a priori reason that requires
>
>   A a = 12;
>
> to be considered as copy initialization (rather than direct
> initialization). It could have been specified that an initializer of the
> form
>
>   = <expression>
>
> is simply equivalent to the corresponding initializer of the form
>
>   (<expression>)
>
> This would not have precluded defining copy-initialization as it is now
> and to use it for implicit initializations (e.g. of function arguments
> and return values).

Not to mention the corresponding assignment:

A a;
a = 12;

> A different decision was taken on this, but in some cases it has
> unpleasant or unexpected consequences.
>
> For example I just recently met the problem that an object must have an
> accessible copy constructor to be declared in a condition.

I also find it unfortunate, because even if compilers are allowed to
optimize the copy away there is no *guarantee* that they will and
because the initialization statement

X y(z /* ,... */);

Is a potential source of bugs, due to its ambiguity.

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.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>=20
> In article <3BFB70B5.F9174A2A@aixigo.de>, Daniel Frey
> <daniel.frey@aixigo.de> writes
> >Hi,
> >
> >in comp.lang.c++ I was told that given a class A with A::A(int)
> >
> >  A a =3D 12;
> >
> >is identical to:
> >
> >  A a(A(12));
> >
> >thus the copy-ctor must be accessible. I simply can't believe that thi=
s
> >is true as it looks brain-damaged to me. Can anyone please tell me tha=
t
> >the folks at clc++ are either simply wrong or that there is some damn
> >good reason for the standard to require the above behaviour instead of
> >declaring 'A a =3D 12' is the same than 'A a(12)' except for 'explicit
> >ctor's'? Help... :))
>=20
> Yes, it does look silly in the example you give, but the rules have to
> work correctly in other cases and we do not want a whole bundle of
> special cases (they are very hard to write correctly)
>=20
> Suppose that I have
>=20
> void foo(A);
>=20
> Do you think foo(12) should always work even if the designer of A has
> carefully made A(int) explicit, i.e. no implicit conversions? You do?

Of course not. That is what I meant by 'except for 'explicit ctor's''
above. The question is: Why 'A a =3D 12;' doesn't equal 'A a(12);' if
there is an implicit conversion available? If reading 'A a =3D 12;', it
should IMHO be a single ctor-call, no temporary that is copied. Probably
a question of what you consider intuitive. Even if the compiler
optimizes it away, it means I have to provide a valid copy-ctor. And
this is the consequence I don't like about the language design here, I'm
not afraid of stupid compilers generating slower code. Of course I
cannot speak for others, but I'd guess that I'm not the only one that
doesn't like to think of 'A a =3D 12;' as a sequence of a temporary being
constructed and used to copy-construct the variable. Is there any
technical reason that would make the above impossible or is it just a
decision based on personal style and preference?

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,

in comp.lang.c++ I was told that given a class A with A::A(int)

  A a =3D 12;

is identical to:

  A a(A(12));

thus the copy-ctor must be accessible. I simply can't believe that this
is true as it looks brain-damaged to me. Can anyone please tell me that
the folks at clc++ are either simply wrong or that there is some damn
good reason for the standard to require the above behaviour instead of
declaring 'A a =3D 12' is the same than 'A a(12)' except for 'explicit
ctor's'? Help... :))

Regards, Daniel

PS: I know that in practice the temporary will be optimized away, but
it's a question that may influence a classes design and it seems that
different compilers have different opinions about the above.

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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.research.att.com/~austern/csc/faq.html                ]