Re: C v C++

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Well its hard to blame a whole design method for every form of code bloat
and yes, I agree that a lot of it has to do with bad design and poor
management of a project. Still, with OOD there is some non-trivial overhead
that goes with the implementation and the method itself leads to a kind of
over-generalization that can make the code expand in size from what might be
a more optimal solution. You get flexibility, ease of enhancement and
reusability out of that sort of design, but you're paying for it by having
the code increase in volume.

I don't think OOD is the worst offender, but it certainly contributes. Its
also not necessarily a problem that code may be more bloated than it
absolutely has to be. Depends on what you're doing...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:JGNN7.872$ea1.327201861@newssvr30.news.prodigy.com...
>
> For poorly-done OOD, yes.  Otherwise I do not find it inherent.  There
> certainly is the school of thought that absolutely every "class" must be
> perfectly complete for every conceivable use, and for some things I buy
that
> and it could be a factor, but in general I do not.  In the bad old days
> there was no way to remove unused routines, so all the code in a package
> would be included in the executable -- and that can certainly lead to
> bloat -- but those days are gone.
>
> For my 2 cents code bloat is a result of poor design and poor management
> (e.g. feature/requirements creep).
>
>
> --
> ---
> Patrick Rogers                       Consulting and Training in:
> http://www.classwide.com          Real-Time/OO Languages
> progers@classwide.com               Hard Deadline Schedulability Analysis
> (281)648-3165                                 Software Fault Tolerance
>
>