🚀 go-pugleaf

Matt Austern (matt@godzilla.EECS.Berkeley.EDU) wrote:

|> In article <4638jp$ef4@fsgm01.fnal.gov> b91926@fsgm01.fnal.gov (David Sachs) writes:

|> > X x(a) uses higher priority conversion by overloading rules
|> > 
|> > X x=a uses X(a.operator X&)

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

Except that there is no guarantee that the copy constructor will
actually be invoked.  The compiler is allowed to optimize it away.

|> Section 12.6 of the working paper explains this in detail.  The rest
|> of chapter 12 is somewhat relevant too.

Concerning the original posting: I don't think it will work.  As I
understand what you are suggesting:

    class B {} ;
    class D : public B { operator B() ; } ;

    D               aD ;
    B               aB( aD ) ;
    B               anotherB = aD ;

What you are saying is that in the first case, D::operator B() will not
be considered, and in the second case, it will be used.

In fact, in both cases, it will be considered, but as a user defined
conversion, it is pretty far down on the scale; in both cases, the
derived->base conversion will have precedence.  (I believe.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

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