Sonny said:
"Victor Bazarov" <
[email protected]> wrote in message
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
