In article <9407251559.AA01149@tdat.ElSegundoCA.NCR.COM> swf@ElSegundoCA.NCR.COM writes:
>One can even go further with this.  Now that C++ has multiple inheritance,
>you can design "features" like persistance as what are called "mix-in"
>classes, to be added to the inheritance tree as needed.
>
>For instance, given the user-defined class:
>
>class Dingbat {
> ....
>};
>
>one can make a persistant version of it as follows:
>
>class PersDingbat : public Dingbat, public PersObj {
>};
>
>This is the accepted C++ way.

 GET IT RIGHT!

 class vPersDingbat
  : public virtual Dingbat, public virtual PersObj { .. }

PLEASE. USE _VIRTUAL_ PUBLIC INHERITANCE. Public nonvirtual inheritance
is a special optimisation trick that INTERFERS with proper library
design by preventing further mixins. Use it in finished application
programs NOT IN LIBRARIES.

Here's why:

 class Vampire { .. };
 class PersVampire : public Vampire, public PersObj { .. };
 class PersDingVampireBat : public PersVampire, public PersObj { ..};

WOOPS! We have TWO copies of PersObj. Thats wrong. We only want one:
persistence is a concept that an object can _be_ or _not be_ and not
something that an object can have a certain number of.

You can _fix_ this by:

 class PersDingVampireBat : public Vampire, public Obj ,
  public PersObj { ..};

but the "fix" is no good -- a PersDingVampire is not a PersVampire
and so cant be used where one is required. Polymorphism fails.

Now try:

 class vPersVampire : public virtual Vampire,
  public virtual PersObj { .. }

 class vPersDingVampireBat : public virtual vPersVampire,
  public virtual vPersDingBat { ..};

Only _one_ copy of PersObj.

RULE of THUMB: In general, if a class is abstract or represents a concept,
derive from it using public virtual inheritance. Public virtual means "isa".

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

Hi there,

I've been programming for a while now in Smalltalk and I just started to
look into C++ as an alternative programming language.

Something bothers me on C++ (especially on the libg++ library) :

Why doesn't there exist a general class "Object" which is an abstract class
for everything in C++.

Why -> I'm thinking of building a sort of standard interface to make objects
persistant. Therefor I would like to have a general way of describing a class
so that a "save" function would be able to get info on the structure of the
class and would be able to get the basic data out of the object and save
it in a datafile (or a table of an RDBMS) . For this I would require e.g. an
array of "Object"'s which would consist of "Integer"'s "String"'s and so on
describing the interface between an object's variables and the persistance
storage manager.
--
Gerrit Cap
Vlaamse Televisie Maatschappij N.V.  e-mail :   gerrit@vtm.be
Medialaan 1     fax    : +32 2 253.12.21
B-1800 Vilvoorde Belgium   voice  : +32 2 255.38.72

In article <CtFu50.8nD@vtm.be> gerrit@vtm.be (The Administrator) writes:
>From: gerrit@vtm.be (The Administrator)
>Subject: Newbie question on class hierarchy
>Date: Sun, 24 Jul 1994 09:24:36 GMT


>Hi there,

>I've been programming for a while now in Smalltalk and I just started to
>look into C++ as an alternative programming language.

>Something bothers me on C++ (especially on the libg++ library) :

>Why doesn't there exist a general class "Object" which is an abstract class
>for everything in C++.

You might turn that question around and ask "Why the frick does Smalltalk
insist on deriving everything from Object?"

To answer your question: CHOICE! To be, or not to be. To be derived from
StorableObject, or from no object. To be virtual , or not virtual? To use
templates, or not to use templates.

To answer my own question: Quite clearly, freedom of choice is very patriotic
and American; fixed menus and simpleton languages are devices used by
communist party members to control a destitute populace.

(Still trolling.... :)

Mike.

 In article <CtFu50.8nD@vtm.be> gerrit@vtm.be (The Administrator) writes:
    Hi there,

    I've been programming for a while now in Smalltalk and I just started to
    look into C++ as an alternative programming language.

    Something bothers me on C++ (especially on the libg++ library) :

    Why doesn't there exist a general class "Object" which is an abstract class
    for everything in C++.

    Why -> I'm thinking of building a sort of standard interface to make objects
    persistant. Therefor I would like to have a general way of describing a class
    so that a "save" function would be able to get info on the structure of the
    class and would be able to get the basic data out of the object and save
    it in a datafile (or a table of an RDBMS) . For this I would require e.g. an
    array of "Object"'s which would consist of "Integer"'s "String"'s and so on
    describing the interface between an object's variables and the persistance
    storage manager.

Very simple. Just because you want to add persistent classes, I would have to pay
for the overheade when I write "int a = b++;" :-)

Seriously, as Dr..Stroustrup describes in his (absolutely worth reading) book ``The
Design and Implementation of C++'', it was one of the C++ design goals to provide
the commonly necessary stuff in the language, while leaving lots of interesting
things (like concurrency, persistence, IPC - you name it) to 3rd party libraries.

More to the point of you're problem: You could create you own class and derive
standard-type interfaces from it:

class PersObj {
  public:
    PersObj();
    virtual bool save() = 0;
    virtual bool restore() = 0;
};

class PersInt : public PersObj
  public:
    // Allow easy construction
    PersInt(int i) : Value(i) {};

    // Allow easy conversion
    operator int () const { return Value; }
    operator int& () { return Value; }

    virtual bool save() { ... }
    virtual bool restore() { ... }

  private:
    int Value;
};

This way you could use your PersInt class just like an ``int'' (well, almost :-)).
And you would be able to use ``real'' (builtin) integers if you want to do something
fast that doesn't need persistence.



    --
    Gerrit Cap
    Vlaamse Televisie Maatschappij N.V.  e-mail :   gerrit@vtm.be
    Medialaan 1     fax    : +32 2 253.12.21
    B-1800 Vilvoorde Belgium   voice  : +32 2 255.38.72

Stefan
--
__________________________________________________________________
Stefan Tilkov                                MLC Ratingen, Germany
                                                st@mlc-ratingen.de
                                        Phone +49 (0) 2102 8506 20
                                        Fax   +49 (0) 2102 8506 30

In article <mikey.167.0005A629@mcs.com>, Mike Young <mikey@mcs.com> wrote:
>In article <CtFu50.8nD@vtm.be> gerrit@vtm.be (The Administrator) writes:
>>From: gerrit@vtm.be (The Administrator)
>>Subject: Newbie question on class hierarchy
>>Date: Sun, 24 Jul 1994 09:24:36 GMT
>
>
>>Why doesn't there exist a general class "Object" which is an abstract class
>>for everything in C++.
>
>You might turn that question around and ask "Why the frick does Smalltalk
>insist on deriving everything from Object?"

 Because Smalltalk doesn't support multiple inheritance.  There's
 no other way to support things like persistance than to put them
 in a _common_ base class - yuck!

 dave
--

In article <CtFu50.8nD@vtm.be> gerrit@vtm.be (The Administrator) writes:
>
>Hi there,
>
>I've been programming for a while now in Smalltalk and I just started to
>look into C++ as an alternative programming language.
>
>Something bothers me on C++ (especially on the libg++ library) :
>
>Why doesn't there exist a general class "Object" which is an abstract class
>for everything in C++.

 NO! DONT! This is the very LAST thing you want to
do in C++. Smalltalk OO and C++ OO are quite different.
DONT try to use Smalltalk techniques in C++: they defeat the
purpose of static type checking, one of C++ major strengths.

 Why isnt there a class Object? Because the only universal
type would have no methods. So it would be useless without
downcasting which is usually bad practice.

 In Smalltalk, you have dynamic message binding: you can
send any message to any object and the object will respond
if it has a method for that message. In C++ you must know
at COMPILE time that the object has a method for the message.
So a methodless universal class is useless.

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

In article <ST.94Jul24135815@tl.mlc-ratingen.de>, st@tl.mlc-ratingen.de (Stefan Tilkov) writes:
|>
|>  In article <CtFu50.8nD@vtm.be> gerrit@vtm.be (The Administrator) writes:
|>     Hi there,
|>
|>     I've been programming for a while now in Smalltalk ...
|>     Why doesn't there exist a general class "Object" ...
|>     for everything in C++.
|>
|>     Why -> I'm thinking of building a sort of standard interface to make objects
|>     persistant. ...
|>
|> Very simple. Just because you want to add persistent classes, I would have to pay
|> for the overheade when I write "int a = b++;" :-)
|> ...

I would like to add that trying to program in C++ as if it were Smalltalk
interferes heavily with library interfaces.  Trying to add a universal
base class makes it hard to import new libraries, and libraries which
implement their own universal base class do not play well with other
libraries.

So, Gerrit, squash your desire for Smalltalkish C++ programs, and learn
how to work within the C++ paradigm (see below).
|>
|> More to the point of you're problem: You could create you own class and derive
|> standard-type interfaces from it:
|>
|> class PersObj {
|>   public:
|>     ...
|> };
|>
|> class PersInt : public PersObj
|>   public:
|>     ...
|> };
|>

One can even go further with this.  Now that C++ has multiple inheritance,
you can design "features" like persistance as what are called "mix-in"
classes, to be added to the inheritance tree as needed.

For instance, given the user-defined class:

class Dingbat {
 ....
};

one can make a persistant version of it as follows:

class PersDingbat : public Dingbat, public PersObj {
};

This is the accepted C++ way.

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.