NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/cplus/16366

Internet Message Format | 1992-11-16 | 1.8 KB

Path: sparky!uunet!ukma!wupost!usc!news!nic.cerf.net!hlf
From: [e-mail] (Howard Ferguson)
Newsgroups: comp.lang.c++
Subject: Should I use a generic object which all others inherit from
Message-ID: <[e-mail]>
Date: 16 Nov 92 16:38:04 GMT
Sender: [e-mail]
Organization: CERFnet
Lines: 34
Nntp-Posting-Host: nic.cerf.net

I am working on the early stages of design on an embedded C++
project. One of the decisions which we will have to make in the
near future is whether to make all of the objects inherit from
onie generic object at the top of the tree or to go for the forest
approach.

I realise that the tree style will make certain  garbage collection
methods easier, but hopefully we are going to be able to create
everything at start-up time and never destroy them (except
for objects with scope local to one function). The only other
advantage of the generic object approach as far as I can see is
that it make hetrogenous lists easier to manage, but since all
of our type checking is gone, are we as well off using void *'s.

The NIH class library encourages the generic object approach, as
does COOL, but USL allows the forest approach. Since we have
not decided which library of standard objects to use, that decision
will be heavily influenced by our decision on whether to go for
the tree or forest approach.

Do any of you netters have any hard-and-fast rules about when
to go for the tree and when to go for the forest aproach.
Is there a big performance price top be paid for the tree approach.
Does the tree have other advantages which I have not noted???

Bear in mind that this software must be very reliable and any
factors which effect this are very important to us. How much
type checking are we really losing by going for a generic approach??


        Many thanks,
            hlf