🚀 go-pugleaf

Jean-Rene Bouvier <jr@isoit109.bbn.hp.com> writes:
	...
>1. is my understanding correct (i.e. that a DerviedObject*& cannot be passed
>   in lieu of an Object*&) ?

>2. what is the reason for this restriction, or rather, is there any reason to
>   keep this restriction (apart from the fact that a DerviedObject*& bears no
>   inheritance relationship to an Object*&) ?
	...
>      DerivedObject** could be passed to a function expecting an Object**,

It would violate type-safety.  It may be easier to see with pointers to
pointers:

class B {
public:
	// whatever
};
class D: public B {
public:
	void aMethodOnlyDhadAnd_NOT_B();
	// whatever else
};

B b;

void tricky(B ** pointer_to_pointer)
{
    *pointer_to_pointer = &b;
}

void ingenue()
{
    D d;
    D* pd = &d;

    tricky(&pd);

    pd->aMethodOnlyDhadAnd_NOT_B();
}

Can you see that type safety is "transparently" violated?  Without
any cast or other unsafe construct, JUST because this hypothetical
version of the C++ language allows passing a D** where a B** is
expected, poor ingenue() function finds itself with a content for
pd which is *NOT* a pointer-to-D!  Then of course it uses pd as
if it WAS a pointer to D (why shouldn't it?!), and, ka-BOOM!
If we were talking about references to pointers, the only difference
would of course be to have the type-safety hole even more hidden
and transparent...  So, clearly, the above code snippet needs a
compile-time error somewhere -- and where could that be, except
in the argument-type-mismatch between the declaration of tricky()
and the call to it?

This is, in a way, related to of the old problem that a bag-of-apples
is-NOT-a bag-of-fruit (even if an apple is-A fruit) *under mutation*
(because if you passed it to a function treating it as bag-of-fruit,
it could insert in it a banana, thus violating semantic constraints
[class invariants] of bag-of-apples).  [_that_, in turn, can be more
abstractly related to the problem that a circle is-NOT-an ellipse
*under mutation*, because a rescale(mX,mY) would violate the semantic
symmetry constraint of class circle...].  The presence of mutators
makes is-A determinations far from intuitive sometimes...!


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