Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!glinda!smith
From: smith@glinda.ctron.com (Larry Smith)
Newsgroups: comp.software-eng
Subject: Re: OO Design with "C" - Do we still get benefits
Message-ID: <1353@glinda.ctron.com>
Date: 25 Mar 91 14:16:52 GMT
References: <1991Mar22.212448.21375@news.larc.nasa.gov>
Organization: Cabletron Systems Inc.  Rochester, NH
Lines: 92

Tried to email this, but it bounced:
In article <1991Mar22.212448.21375@news.larc.nasa.gov> smd@rehder.larc.nasa.gov (Steve Dahmen) writes:
>Would anyone here mind commenting on the use of object oriented 
>analysis and design principles with the "C" language?
>
In my experience, mostly with the Motif widgets, any attempt to use C for o-o
programming will lead to a large morass of Obfuscated C Contest material.

>From my own limited, but growing, understanding of OOD, it seems the
>concepts itself natually promote good programming practices resulting
>in lower maintenance costs.  Our project seems to invite an OO
>approach because of the data organization.
>I considered using C++, but none of
>the developers here are trained in it, we don't have decent manuals
>for it, we'd rather not take out time to get a compiled compiler on
>our machines, and chances are we won't want to pay for developers with C++

That is true.  Object-oriented design is the only new coding technology to have
proven benefits to modern software construction.  But, sadly, I must state that
C just does not support it well, and you will spend more time enforcing the
discipline needed to do o-o programming in C than if you had gotten a copy
of AT&T cfront and used that.  For all that C++ is basically a superset of
C, it's best use makes it a whole new langauge.  The advantage for you is that
it makes your learning curve less steep.

>knowledge just to maintain the code. And ADA, well, that's a whole
>nother ball of wax; yet I don't think Silicon Graphics has an ADA
>compiler anyways.  In addition, we don't need to
>implement some of the more object language-oriented  features such as
>the real-time messages, etc.  And lastly, we intend to share this code

This statement is meaningless.  Exactly what *is* a "real-time message" and
how come I have never run into the term in ten years of o-o programming?
If you are referring to message-passing, the concept does not exist in C++,
it's a "method call" and works just like a function call. If you're talking IPC,
it's IPC, and the language is irrelevent.  If you are confusing IPC with
Smalltalk-like "message passing" go and get a book on the subject, you don't
know enough about object programming.

>with other aerospace engineers, who undoubtedly will not speak C++ or
>Ada.

If they can't can't learn enough C++ to read your code they are not smart
enough to deal with the weird code and funny organization you will need to
do object-oriented programming in C.

>
>SO, is there a tragic flaw in my assumption that the use of OOD in
>analysis and design, but implementing the project in "C" will result
>in "better" code than using the old functional decomposition methods?
>Does anyone have any idea if such an implementation will cause the
>application to run any slower than a functionally decomposed
>implementation??

Object-oriented code runs as fast as any other kind unless you use special
features provided by most object-oriented languages as tools.  Such things as
late binding and multiple inheritance *do* cost time.  Straightforward use
of object-orientation with compile-time binding costs nothing.  Note that these
features are usually provided, but are not truly needed, for o-o design.  They
are a convenience.  A very great convenience, to be sure, but a convenience,
not a necessity.

Object-oriented systems will *always* be easier to build and maintain than
traditionally-structured programs and FAR easier than the usual hacked messes
that pass for "modern software".  But it requires foresight and a clear
design to get maximum code re-use and flexibility.  You can't start coding
o-o software without clear goals in mind, you will *never* finish and you
will *never* have bug-free software.
>
>Lastly, might there be any SE papers out there connected with this
>topic?

Lot's of them.  SP&E has a lot them, SIGPLAN often has discussions, but it
sounds like you really need a basic course in the subject.  There are a number
of good books on the subject, but it's been years since I read any, so I will
leave it up to others to give you more concrete suggestions.
>
>Thanks in advance for your insights,

One insight that you might find useful: memory management is a total nightmare
in a large o-o application.  C++, with its constructors and destructors, and
other such tools is only *barely* adequate to do the job.  Finding the massive
memory leaks that any significant application will have is a long and terribly
terribly painful exercise.  The very worst package for this sort of thing -
lost memory and bashed memory structures due to dangling pointers - that I have
ever seen is the Motif widgets package from OSF.  It is unquestionably the
worst, it leaks huge amounts of memory, it is delicate to fix bugs in, it's
organization is a nightmare and it is all object-oriented and in C.  Save
yourself, get C++.

Larry Smith
smith@ctron.com