C v C++

C v C++

[Martin Dowie]

Has anyone been following the thread

"What is code bloating ? What leads to code bloating in C++?"

in "comp.lang.c++"?

If I was being cruel, I'd compare this to
a blind man fighting a sighted man in a dark room!

It seems like the C++ guys are now having to fight
the same language/compile bloat issues that I've
heard often enough around Ada! :-)

Re: C v C++

[Marin David Condic]

Code bloat seems to me to be (at least in part) a consequence of Object
Oriented Design. I recall hearing someone at a TriAda conference years ago
describing OOD as: "If you want a banana, you have to take the whole
gorilla." You may gain something with OOD, but you sacrifice something for
it as well. I'd see this as a problem for both Ada95 and C++ when you use
the OO model so I would be reluctant to pick on C++ for it.

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/


"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
news:3c075b22@pull.gecm.com...
> Has anyone been following the thread
>
> "What is code bloating ? What leads to code bloating in C++?"
>
> in "comp.lang.c++"?
>
> If I was being cruel, I'd compare this to
> a blind man fighting a sighted man in a dark room!
>
> It seems like the C++ guys are now having to fight
> the same language/compile bloat issues that I've
> heard often enough around Ada! :-)
>
>
>
>

Re: C v C++

[Pat Rogers]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9u851b$7d$1@nh.pace.co.uk...
> Code bloat seems to me to be (at least in part) a consequence of Object
> Oriented Design. I recall hearing someone at a TriAda conference years ago
> describing OOD as: "If you want a banana, you have to take the whole
> gorilla." You may gain something with OOD, but you sacrifice something for
> it as well. I'd see this as a problem for both Ada95 and C++ when you use
> the OO model so I would be reluctant to pick on C++ for it.

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

Re: C v C++

[Marin David Condic]

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
>
>