"Sonny" <sl**@pacbell.net> wrote...
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:<hFXTb.170807$sv6.919779@attbi_s52>...
"Sonny" <sl**@pacbell.net> wrote... I need to port a library that is written entirely in C to C++. The
library is supported on quite a few platforms (windows, Solaris,
Linux, AIX, HP-UX, OSX, etc...) and there's quite an existing customer
base that uses it. I need to maintain backwards compatibility such
that existing users won't have to do anything to their existing
applications other than a re-compile when they upgrade to this new
version of the library. I figure that I can rewrite the library in
C++ and provide a C interface for backwards compatiblity. Is my
thinking too simplistic?
Simplistic would be just recompile your library with a C++ compiler
and be done with it. No need to rewrite.
I'm sure that there are issues that come
into play when doing this, but I can't really think of any. I'm a C
programmer who hasn't done any C++ in quite a few years so if this is
a dumb question, please excuse my ignorance.
The main stumbling point in such situations for me is "why?" What
are you expecting to gain by porting from C to C++?
Victor
The existing C code base is very old (which isn't necessarily a bad
thing), not well documented (which makes it very difficult to
maintain), and very buggy and difficult to maintain. The idea is to
rewrite everything in C++, expose a C interface and put to rest the
existing C code base out to pastor.
Then "porting" is the wrong term for what you're about to undertake. The
proper term would be "rewriting". So, your thinking is not too simplistic
but the word you used in the subject line probably makes you think the task
is easier than it can be. Rewriting is often done because the old code base
has severe limitations and/or not a subject to maintenance. It is usually
not as simple as some might want to think, and using an incorrect name for
the process doesn't help either.
You can take one of two path, IMHO. Perhaps more or, rather, some kind of
combination of the two.
One is to keep the old system as the specification and write the new one
fresh, while making sure it does what the old one was supposed to. This
approach has its disadvantages, of course, and the main one is that there
are going to be _new_ bugs introduced into the new code, and the behaviour
is going to be different because of that. Another disadvantage is that
you will need to design the system (some see it as a good thing, at least
you will know how the system works, but to me there is a time factor). No
doubt, you will have to keep the interface changes at zero. You may only
add to it.
The other is to fix the old system, bring it up to date and up to snuff.
The disadvantage of this approach is that you really need to know what the
old system does and how it does that. So, you will need to figure this out
while fixing it. Besides, you have to work with the older style and
language, which is not necessarily an option (if you aren't so good with C,
for example).
Of course, each of those two ways will keep the code base in some form.
The former will probably keep the C headers and the "shell" of the old
functions, which you will have to populate with new C++ functionality. The
latter will keep most of the functionality intact with patches of new or
fixed code throughout. You could even try to bring some of the functional
code from the old system into the new, if taking the former approach. Is
that a good idea? You will have to decide. But remember that while you
might want to keep working algorithms around, are you sure they are working
and bug-free?
In any case, what you really need is documentation, and nothing is going to
help you create one. You either write it based on what customers tell you
they need, or you write it by looking at what the old system does (or at
least seems to do), that's all for backward compatibility. You cannot
escape the necessity to have such documentation, if only for the sake of
future maintainability of the system.
I've done several such "ports" in my career, and only one thing I can tell
by looking back is that the latter approach, while less attractive, can
actually work better. While seemingly fun ("I get to design the new
system while making it work with real-world existing solutions"), the
former is 99% headache and only 1% excitement.
Good luck!
Victor
