Guus C. Bloemsma (guus@proxim.franken.de) wrote:
> In article <D71nF1.DHo@cix.compulink.co.uk> mwoolf@cix.compulink.co.uk
> ("Matthew Woolf") writes:
> > class MySpecializedClass:public *BaseClass ...or...
> > class MySpecializedClass:public &BaseClass

> There is a discussion about this in D&E. The basic problem is overriding
> inherited methods. Some function expects a pointer to BaseClass, so you
> have to dereference the implicit pointer before calling it. Now this
> function calls a method of BaseClass that you overrode in
> MySpecializedClass. How does this method obtain a pointer to the extra
> data of MySpecializedClass?

As long as the base objects are newly allocated, and not just arbitrary
objects of the base class, the necessary information could be allocated
in front of the "real base object". Routines which expect the base type
objects will receive a pointer to the normal base object, and functions
which are redefined in the inheriting class know the layout of the pre-
fix area which points back to the "real self" (and may have any further
data which the compiler finds useful for such problems). Fundamentally,
you implement inheritance with delegation, and parents are shared parts
(as they expressed it nicely for Self). I think the techniques for this
aren't really the problem, but whether the additional complication will
be worth the benefit. It may be better to invest one's time into really
fast compilers, compilation databases with fine dependency analyis, low
granularity in linked object code (i.e. linking only the data/functions
which are needed, not each object file for which anything of the source
file is needed), intermediate codes which only need to be adapted for a
particular memory layout, etc. All such things are worth having anyway,
and solve the problem without runtime overhead. Problems of development
time should be solved by improving the development environment (if that
possible with reasonable effort - and looking over to the technology in
Ada environments, or module linking in the Oberon system, may provide a
good first impression of what's already being used now). C++ has "some"
;-) more problems due to the preprocessor, but that's a matter of work,
not a fundamental question (at least for this round of the standard).

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>

In article <D71nF1.DHo@cix.compulink.co.uk> mwoolf@cix.compulink.co.uk
("Matthew Woolf") writes:
> To remove the (efficient but annoying) dependancy that inheitance
creates
> by including all the base class's members in the memory of the client
app
> (assuming the base is implemented in a "black-box" library), how about
> inheritance thru pointers (or references), by introducing the syntax.
>
> class MySpecializedClass:public *BaseClass ...or...
> class MySpecializedClass:public &BaseClass
>
> That way, I could re-impment the base class without the need to
> re-compile my client app. As an implementation, the default could be to
> use BaseClass::new to initialise the hidden pointer member of
> MySpecializedClass when it (the decendant) is constructed and delete
when
> it is destroyed.

There is a discussion about this in D&E. The basic problem is overriding
inherited methods. Some function expects a pointer to BaseClass, so you
have to dereference the implicit pointer before calling it. Now this
function calls a method of BaseClass that you overrode in
MySpecializedClass. How does this method obtain a pointer to the extra
data of MySpecializedClass?

Good Luck, Guus Bloemsma.

To remove the (efficient but annoying) dependancy that inheitance creates
by including all the base class's members in the memory of the client app
(assuming the base is implemented in a "black-box" library), how about
inheritance thru pointers (or references), by introducing the syntax.

class MySpecializedClass:public *BaseClass ...or...
class MySpecializedClass:public &BaseClass

That way, I could re-impment the base class without the need to
re-compile my client app. As an implementation, the default could be to
use BaseClass::new to initialise the hidden pointer member of
MySpecializedClass when it (the decendant) is constructed and delete when
it is destroyed.

The important logical (virtual :->?) difference from straight association
with custody is that the same "inheritaned" syntax can be used -
separating inheritance through a pointer from composition as C++
currently does:

MySpecializedClass anObj ;

anObj.BaseFunc() ;      // Compiler generates de-reference yo
anObj.pBaseClass->BaseFunc()

Thoughts on possible implementations or better waays of achieving the
same thing very welcome.