From: kanze@us-es.sel.de (James Kanze)
Subject: Re: Need help implementic data structures of generic objects
Organization: SEL
	<MATT.92Dec11162629@physics.berkeley.edu>
	<1992Dec13.002551.778@informix.com>
Date: 15 Dec 92 21:15:34

In article <1992Dec13.002551.778@informix.com> cshaver@informix.com
(Craig Shaver) writes:

    [Quoted postings deleted...]
|> This group seems to be biased against inheritance techniques in all cases.

I haven't noticed this, and I read the group pretty regularly.

    [Flame deleted...]
|> It is obvious to me that you have a virtual function in the base class for 
|> all functions that you need to use when dealing with 'Objects'.

But you don't know what all of the functions are that you will need.

Regrettably, I didn't save the original posting which started this
thread, so I'm not completely sure what the original posters question
was.  But deriving all classes from Object (or Root, or Top) is
usually done in order to write a generic container class, which
contains Object's (or whatever).

This is *not* the way to do it in C++.  The normal solution is to
write the generic container class as a meta-class, and instantiate it
for each type of container needed.  (In modern C++, you use templates
to define a meta-class.  If you only have an older compiler, like I
do, then you make do with the generic package.  Conceptually, they're
the same thing, although at the implementation level...)

This idea didn't originate with C++; it is present in Ada.  But by
combining it with classes and inheritance, it becomes far better than
what Ada offered.

|> If you use a function on a class that is only restricted to a certain
|> sub-tree of your inheritance structure, then you know what you are using,
|> ergo, you should have used that type instead of 'Object'.

That's what we've been saying all along.  This seems an argument
against your point of view.

|> IMHO, if you do not use inheritance, you are not doing OOP.  If you do
|> not care, then you are just using C++ as a variation on C with no real
|> benefit.

Well, I don't do OOP *just* to do OOP.  I use it as a means to an end.
One of the means.  And I tend to use a lot of inheritance.  But not
for the sake of inheritance, but because it corresponds to the model
of what I'm doing.

If you take my String class, for example, you will find *no*
inheritance.  Because the real world strings that I'm modelling are
primitive types themselves, and not a type of anything else.  Adding
inheritance (of what?) would just be excess bagage.

On the other hand, my container classes *do* inherit.  Because an
associative array of String's (for example) is a type of an
associative array.  There's inheritance in what I'm modelling, so
there's inheritance in my program.

Since in most non-trivial programs, we have to consider several layers
of abstraction in the modeled objects, most non-trivial programs will
use inheritance.

    [I couldn't make much sense out of the rest of the posting; it
sounded more like ranting and raving than any sort of argument.  So
I've cut it.  Some one else can answer if they want to.]
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung
Newsgroups: comp.lang.c++
From: nikki@trmphrst.demon.co.uk (Nikki Locke)