By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,645 Members | 1,125 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,645 IT Pros & Developers. It's quick & easy.

Porting library from C to C++ but must maintain backwards compatibility

P: n/a
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? 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.

Thanks,
Sonny
Jul 22 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"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
Jul 22 '05 #2

P: n/a
Sonny,

Drop me a line if you want an example project for the gcc tool chain
that implements your specs.

Evan Carew

Sonny 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? 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.

Thanks,
Sonny


Jul 22 '05 #3

P: n/a
"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.

Sonny
Jul 22 '05 #4

P: n/a
"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
Jul 22 '05 #5

P: n/a
"Victor Bazarov" <v.********@comAcast.net> wrote in message news:<utaUb.174776$sv6.929955@attbi_s52>...
"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


Hey Victor,

Thanks for the reply. I'm leaning towards doing the former as one of
my colleages did a re-write of the library in Java not too long ago.
I figure that I can use that as a starting point. Patching the
current code base isn't really an option anymore because it's so
convoluted that IMO, figuring what it did would take more time that
rewriting it from scratch. My main concern is backwards
compatibility. I've been told that if a customer upgrading to this
new version of the library needs to do anything other than plug it in
and recompile, it's a problem. I hope to avoid issues such as where
the version of the compiler I use to build the library isn't
compatible with the version of the compiler my customers use when
integrating the library into their application.

Sonny
Jul 22 '05 #6

P: n/a
Sonny wrote:

Thanks for the reply. I'm leaning towards doing the former as one of
my colleages did a re-write of the library in Java not too long ago.
I figure that I can use that as a starting point. Patching the
current code base isn't really an option anymore because it's so
convoluted that IMO, figuring what it did would take more time that
rewriting it from scratch. My main concern is backwards
compatibility. I've been told that if a customer upgrading to this
new version of the library needs to do anything other than plug it in
and recompile, it's a problem. I hope to avoid issues such as where
the version of the compiler I use to build the library isn't
compatible with the version of the compiler my customers use when
integrating the library into their application.


In that case what you have isn't a porting issue but a
reimplementation. I'd think of it as an entirely new
product, that just happens to retain the same API as the old
one.

Although it depends on the size of the library, personally
I'd favour the second alternative given by Victor. At least
that way you can tackle the work in stages.

I also think that you'll still need to figure out what the
old code is doing if you hope to replace it. The Java
re-write might not help much if you have to maintain the old
C API.

Anyway a couple of years ago we replaced our geometric
solver library written in fortran with code written in C++.
By retaining the old library we were able to gain confidence
in the replacement by calling the fortran equivalent from
within C++ code, comparing the results, and dumping the
program if a mismatch occurred in debug runs. As an added
precaution we added a facility to enable toggling either the
old or new solver implementation. This was so that if
problems were encountered after release, users could
instruct the application to use the old solvers. After a
release cycle and no bug reports the old library was unhooked.
Jul 22 '05 #7

P: n/a
sl**@pacbell.net (Sonny) writes:
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.


An alternative to this could be to rewrite in OO C, and have a C++
wrapper around that. This isn't as stupid as it seems: if you use
GObject and GLib you can wrap your C objects (GObjects!) using Glibmm
and gmmproc to have a very nice C++ binding.

http://www.gtk.org/
http://gtkmm.sf.net/
--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Jul 22 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.