Hi!

I am tring to figure out how efficient it will be to develop C++ or
object oriented code on top of existing functional code.  I am quite
fascinated with the Object Oriented paradigm and it makes sense if
the entire project is designed and developed using the Object Oriented
approach.

But what are the tradeoffs involved of building object oriented code
on top of existing functional (C) code?

I would appreciate it if the C++ gurus could share their thought or
suggest some literature on developing object oriented code on top
of functional code.

I am sorry if this is FAQ.

Thanks!

Bharat

In article <1993May11.180232.16265@tandem.com> bharat@sturgeon.storage.tandem.com (Bharat Venkat) writes:
|I am tring to figure out how efficient it will be to develop C++ or
|object oriented code on top of existing functional code.  I am quite
|fascinated with the Object Oriented paradigm and it makes sense if
|the entire project is designed and developed using the Object Oriented
|approach.
|
|But what are the tradeoffs involved of building object oriented code
|on top of existing functional (C) code?

Depends on what you mean by "efficient" -- C++ code can easily be written
on top of existing C code in such a manner that the resulting executables
are as fast or faster that the previous C code.  The reason being is that
the better encapsulation of C++ allows one to cleanly introduce algorithm
speed ups where such are needed.  For example, MFC encapsulates Windows
message dispatch, and introduces Windows message caching where most needed
to avoid the message lookup time.  Thus MFC is actually faster for common
messaging, such as mouse movements.

If by "efficient" you mean the amount of time required to write a C++
layer on top of a set of C functionality, be forewarned that doing the
job "right" can be extremely time consuming.  Basically the C++ programmer
has to reverse-engineer the C programmers work, try to understand what the
C programmer thought he was trying to accomplish and how, figure out those
areas where the C program blew it, try to come up with a compatible model
that encapsulates these things, and then typically must also allow clean
"escapes" back into calling some or all of this from the C world.
Frankly, much of C code is extreme hackishness, which is what you will
discover when you try to come up with a clean model to fit on top of the
existing C code.  Some of this problem relates to C's memory allocation
limitations, which are even more extreme that C++'s.

Perhaps the biggest problem is typically management, who perceive the
existing C code as a major investment to be recouped, rather than
[in reality] a heaping pile of shit\\\\straw that they are asking you
to spin into gold.

Thus, ideally one learns from past mistakes, and writes new clean code.
But in practice one has prior code that one has to live with.  Just
don't fall into the trap of thinking a C++ wrapper can take away
much of bad C code's smell.  The rare good C code however,
can frequently be made even  better.