🚀 go-pugleaf

In article <606002587wnr@hi-q.demon.co.uk>,
Bryan Drew  <bdrew@hi-q.demon.co.uk> wrote:
>In article: <401gnk$mk0@metro.ucc.su.OZ.AU>  maxtal@Physics.usyd.edu.au (John Max Skaller) writes:

[virtual bases should be abstract]

>> 	If you examine several other problems, however you will
>> probably come to that conclusion as a rule of thumb as I have.
>
>I am not sure I completely agree with you.  

	Probably because I didn't explain well enough.

>I could argue that the
>following hierarchy is a reasonably sensible approach.


	If you did, you would be arguing that there is a fault
in C++. I'm arguing there ISNT and that you have simply failed
to understand the consequences of the language as it is
currently -- and correctly -- defined. [took me 3 years 
to figure this one out]

>    class Person
>    {
>         char* name;
>    };
>
>    class Employee 
>        : public virtual Person
>    {
>        int employee_number;
>    };
>
>    class Golfer
>        : public virtual Person
>    {
>        int handicap;
>    };
>
>    class Company_Golf_Club_Member
>        : public Employee, public Golfer
>    {
>        int rank;
>    };
>
>Here we have the situation where a Golfer IS A Person.  An Employee 
>IS A Person.  And a Company_Golf_Club_Member IS both A Golfer, and 
>AN Employee !!

	No problem. Just get rid of the data!

>N.B. An Employee need not be a Golfer and visa-versa.
>
>This to me would seem to be a natural mechanism to represent the 
>class hierarchy identified above.  

	It would seem so naively, but further examination
proves otherwise: the whole point of your original post 
is that this DOESN'T work very well.

	You argued, as many have before (including me!)
that this is fault in the c++ language.

	It isn't. The language is correct as it stands.
There's no other sensible alternative.

>However the C++ virtual base class 
>mechanism causes the above implementation to take on a number of 
>warts, especially in the use of non-default constructors.

	Yes, so the naive implementation is just that -- naive.
>
>Taking this case in point, a Person must always have a name, date of 
>birth etc., and so to provide a default constructor for such a class 
>is meaningless!  These warts generally lead one away from developing 
>hierarchies that utilise virtual inheritance and hence cause one to 
>pervert the class hierarchy instead!!

	NO. Just do it the right way!

	Here it is: (WILL Someone put this in the FAQ please!!)


    struct Person
    {
         virtual char* name()const =0;
      protected: void operator=(Person const&);
    };

    struct Employee 
        : public virtual Person
    {
        virtual int employee_number() const = 0;
      protected: void operator=(const Employee&);
    };

    struct Person_impl : public virtual  Person {
	char *thename;
	Person_impl(char *n) : thename(n) {}
	char *name()const { return thename; }
    };

    struct Employee_impl : public virtual Employee, public Person_impl {
	int thenumber;
	Employee_impl(char *nam, int num) 
		: Person_impl(name), thenumber(num) {} 
	int employee_number ()const { return thenumber; }
    };


Perhaps you can see how separating the interface and implementation
solves the problems with initialisation -- and at the same time
permits extra representations to be provided.	

This works for multiple inheritance fine.

Yes, it is extra long winded and not necessary for 
"quick one off application programming". But it is mandatory
for a quality OO library class. (IMHO)
	
>My original posting at the start of this thread requested the reasons 
>*why* non-default virtual base class constructors required calling 
>from the most derived class, rather than the lowest class where all 
>the virtual class instances had been inherited.  


	It isn't possible to define such a class coherently and stably.
ANY class further down can just "grab" the class as a virual base.
This leads back exactly to the original problem -- multiple
initialisations.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
	Maxtal Pty Ltd,		    
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21 
        NSW 2037, AUSTRALIA	    Phone: 61-2-566-2189