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

Internet Message Format | 1992-11-18 | 3.8 KB

Path: sparky!uunet!ogicse!emory!sol.ctr.columbia.edu!ira.uka.de!slsvaat!josef!kanze
From: [e-mail] (James Kanze)
Newsgroups: comp.lang.c++
Subject: Re: Should I use a generic object which all others inherit from
Message-ID: <[e-mail]>
Date: 19 Nov 92 00:35:31 GMT
Article-I.D.: slsvdnt.KANZE.92Nov18163531
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: SEL
Lines: 83
In-Reply-To: [e-mail]'s message of 17 Nov 92 19:08:21 GMT

In article <[e-mail]> [e-mail]
(Craig Shaver) writes:


|> In article <[e-mail]> [e-mail] (Howard Ferguson) writes:
|> >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.
|> >
|> .................
|> >
|> >
|> >        Many thanks,
|> >            hlf

|> An embedded system!  C++!?  JUST USE C!!!!

|> UNLESS ....

|> You have some of the benefits of OOP in mind, such as inheritance, reuse,
|> and information hiding.

UNLESS...

You want the added security of additional static type checking,
encapsulation, etc.

I have found that the encapsulation you get from C++ (by writing a
class instead of a struct and some functions) is an even bigger win
than any of the object oriented stuff.

On the project I'm currently working on, we recently had to completely
change the representation and implementation of one class, replacing a
simple, intuitive implementation by one that was more complex, but a
magnitude more efficient.  Incidence on users of the class: 0.  On
every project I've been on, this has been an acknowledge goal.  With
C, however, we were never able to succeed completely.  Here, the class
author didn't even think about it this, but it worked automatically.

|> Then if you are willing to take small dings in
|> performance go all the way and use the tree approach as pioneered by
|> Smalltalk.  I recently saw a review of the toy code that comes with the
|> borland compiler.  The article's author commented that the tree type
|> libraries were "passe" because of templates.  What a stupid thing to say!

The Smalltalk approach is fine for prototyping, but I certainly
wouldn't use it in an embedded system.  Basically, it trades off
compile time checks for run-time checks.

If the compiler says error, you correct the code and recompile.  What
do you do if you get a type error at run-time?

|> One of the big wins of OOP is reuse.  By using an inheritance structure
|> you can reuse existing code and do incremental development.  Related and
|> unrelated classes can be used in the same context where a similar protocol
|> is enforced.

Agreed.

|> I have to think some of the people involved with C++ have no idea what the
|> basis of OOP really is.  They are simply using C++ as an improved C.

Or as an alternative to Ada.  Or because they want some of the
features of Ada, some of Pascal, and some of C.

C++ is not without problems.  The language is big and complex (and
growing daily).  It is difficult for beginners (and sometimes for
experienced people) to understand the interreactions between the
different features.  The closest thing we have to a standard, the ARM,
is full of ambiguities and undefined areas.

But if you just take your C design, convert the struct's to classes,
and make all functions that operate on the struct members, and you've
already got a big win.  Then, as you begin to add inheritance and
classes that are used for their behavior rather than simply to hold
state, you'll find that it gets even better.
--
James Kanze            GABI Software, Sarl.
email: [e-mail]    8 rue du Faisan
                67000 Strasbourg
                France