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

Discussion in 'C++' started by Sonny, Feb 4, 2004.

  1. Sonny

    Sonny Guest

    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
    Sonny, Feb 4, 2004
    #1
    1. Advertising

  2. "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?


    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
    Victor Bazarov, Feb 4, 2004
    #2
    1. Advertising

  3. Sonny

    Evan Carew Guest

    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
    Evan Carew, Feb 4, 2004
    #3
  4. Sonny

    Sonny Guest

    "Victor Bazarov" <> wrote in message news:<hFXTb.170807$sv6.919779@attbi_s52>...
    > "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?

    >
    > 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
    Sonny, Feb 4, 2004
    #4
  5. "Sonny" <> wrote...
    > "Victor Bazarov" <> wrote in message

    news:<hFXTb.170807$sv6.919779@attbi_s52>...
    > > "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?

    > >
    > > 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
    Victor Bazarov, Feb 4, 2004
    #5
  6. Sonny

    Sonny Guest

    "Victor Bazarov" <> wrote in message news:<utaUb.174776$sv6.929955@attbi_s52>...
    > "Sonny" <> wrote...
    > > "Victor Bazarov" <> wrote in message

    > news:<hFXTb.170807$sv6.919779@attbi_s52>...
    > > > "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?
    > > >
    > > > 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
    Sonny, Feb 5, 2004
    #6
  7. Sonny

    lilburne Guest

    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.
    lilburne, Feb 5, 2004
    #7
  8. Sonny

    Roger Leigh Guest

    Re: Porting library from C to C++ but must maintain backwardscompatibility

    (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! =-----
    Roger Leigh, Feb 10, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. duncan
    Replies:
    1
    Views:
    357
    Chris Liechti
    May 4, 2004
  2. Jason Mobarak
    Replies:
    1
    Views:
    253
    =?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?=
    Jul 3, 2004
  3. Orestis Markou
    Replies:
    1
    Views:
    305
    Martin v. Löwis
    Oct 8, 2008
  4. Joseph Benik
    Replies:
    12
    Views:
    162
    James F. Hranicky
    Dec 23, 2003
  5. Brian Candler
    Replies:
    9
    Views:
    157
    John Doxey
    May 6, 2009
Loading...

Share This Page