🚀 go-pugleaf

Distribution:
John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
|> In article <40g1nl$2jo@gabi.gabi-soft.fr>, J. Kanze <kanze@gabi-soft.fr> wrote:
|> >John Max Skaller (maxtal@Physics.usyd.edu.au) wrote:
|> >
|> >|> 	For example how do you do assignments in the presence of
|> >|> virtual bases? What stops the data of the virtual base being assigned
|> >|> more than once?
|> >
|> >	C&
|> >	C::operator( C const& other )
|> >	{
|> >		if ( this != &other )
|> >		{
|> >			this->~C() ;
|> >			new ( this ) C( other ) ;
|> >		}
|> >		return *this ;
|> >	}
|> >
|> >No duplicate assignment of the virtual bases of C.

|> I don't understand, this does NOT work.

Yes it does.  At least, it does according to the standard, and on all
compilers I've been able to try it with.  (It doesn't compile under
certain versions of cfront, due to a compiler error.)

|> This stops
|> an object being assigned to itself. That isn't the problem.
|> The problem is:

|> B
|> / 		L  R
|>  /
|> D

|> If the assignment of D calls the assignments of L and R
|> before assigning the non-inherited members of D, and
|> the assignments of L and R each call the assignment of B
|> before assigning their non-inherited members, then the
|> assignment of B is called TWICE.

No disagreement, except that the assignment operator of D (or C, in my
example) never calls the assignment operator of its base classes.

|> In the case of assigments entirely generated by the compiler,
|> it is possible for the compiler to do the right thing.
|> AFAIK the committee has NOT required this: double assignment
|> is permitted. (I hate this but I can live with it)

|> In the case where USER written assignments are involved
|> AS WELL as compiler generated assignments, there is NO way
|> to ensure the compiler does the right thing.

Why doesn't my example work.

The whole questions hinges on defining what the right thing is.  I would
contend that in many (most?) cases, the right thing is to destruct the
existing target object, and copy the right hand side into it.  This is
*exactly* what my code does.

Since it uses the destructor for destruction, and the copy constructor
for copying, *and* the compiler is required to do these correctly, it
``works''.

Note that typically, it will in fact do extra work, since the generated
code will fiddle around with the vptr's.
-- 
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. ]