🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) writes:
	...
>Alex Martelli (martelli@cadlab.cadlab.it) wrote:
>|> matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:
>|> 	...
>|> >Sort of.  If a is of class A, if the copy constructor X::X(const X&)
>|> >exists, and if the converting constructor X::X(const A&) exists and
>|> >isn't qualified as explicit, then "X x(a)" simply invokes the
>|> >converting constructor while "X x=a" invokes the converting
>|> >constructor and then the copy constructor.
	...
>|> and an implementation optimizing out the copy ctor in this case
>|> would be non-conforming...?  Oh boy, I _am_ confused -- I thought
>|> such sentences in the draft as "Either direct-initialization semantics
>|> or copy-initialization semantics apply" in  [class.expl.init] sub 1
>|> were there to specifically allow such optimizing-out... perhaps it

So, apparently, from what Mr Kanze and Mr Clamage respond, I wasn't the
one being confused -- Mr Austern was, or perhaps he just omitted
reminding readers that "X x=a" is allowed to _either_ invoke the
converting ctor then the copy ctor, OR optimize the latter out,
i.e. it's allowed to believe just like "X x(a)", _except_ for the
case where the copy ctor is not accessible.


>(There is an interesting question here.  Suppose that the copy
>constructor is declared public, but no implementation is given.  I think
>that under the current rules, the compiler is required to give a
>diagnostic.  In practice, I'm willing to bet that none of the compilers
>which optimize out the copy constructor do.)

In general, do violations of the ODR require mandatory diagnostics?
I thought they didn't, so why would one be mandated here...?


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]