STL and shared libraries

Discussion in 'C++' started by Steve, Nov 12, 2005.

  1. Steve

    Steve Guest

    Hi,

    We have an application framework library that gets statically linked to any
    applications we produce. (Windows apps, but I don't think that matters
    here).

    The framework is based heavily on the STL and the API uses many STL
    constructs. Because of the static linking, and the fact that both app and
    framework are built by the same compiler, we don't have any problems.

    Now somebody has suggested we make the framework a shared library.

    Of course, this probably means a big re-write is on the cards, and I am
    aware that there can be issues if std::strings and other STL templated
    classes are exposed on a shared library API.

    Has anyone here had to tackle this problem? Any advice would be most
    welcome. (Is there a common design pattern one could follow?)

    I guess this is the reason why C++ libraries like QT and xerces provide
    their OWN classes instead of using STL, right? :)

    Thanks.

    --
    Regards,
    Steve

    "...which means he created the heaven and the earth... in the DARK! How good
    is that?"
    Steve, Nov 12, 2005
    #1
    1. Advertising

  2. On Sat, 12 Nov 2005 18:45:14 GMT, Steve <root@127.0.0.1> wrote:

    >Hi,
    >
    >We have an application framework library that gets statically linked to any
    >applications we produce. (Windows apps, but I don't think that matters
    >here).
    >
    >The framework is based heavily on the STL and the API uses many STL
    >constructs. Because of the static linking, and the fact that both app and
    >framework are built by the same compiler, we don't have any problems.
    >
    >Now somebody has suggested we make the framework a shared library.
    >
    >Of course, this probably means a big re-write is on the cards, and I am
    >aware that there can be issues if std::strings and other STL templated
    >classes are exposed on a shared library API.
    >
    >Has anyone here had to tackle this problem? Any advice would be most
    >welcome. (Is there a common design pattern one could follow?)
    >
    >I guess this is the reason why C++ libraries like QT and xerces provide
    >their OWN classes instead of using STL, right? :)
    >
    >Thanks.


    As long as you keep to the same environment (i.e. same compiler, etc.)
    there's nothing inherent about the STL which would preclude making a
    shared library with components which use it, as long as the clients
    using the shared library are also compiled with the same compiler.

    It all depends on how it is used, of course. You have to be
    particularly careful with memory management issues when using shared
    libraries, i.e. creating an object with "new" in one module and
    destroying it with "delete" in a different module is definitely
    something to avoid. The only way this can possibly work is if ALL
    executables and libraries involved use the same C runtime library. And
    the only way this would work is to link the CRT dynamically.

    A good (and important) design pattern for this problem is the
    "abstract factory". You would typically do the creation and
    destruction of objects in the same factory class, exposing
    Factory::Create() and Factory::Destroy() functions, instead of relying
    on the clients to call new and delete.

    --
    Bob Hairgrove
    Bob Hairgrove, Nov 12, 2005
    #2
    1. Advertising

  3. Steve

    Steve Guest

    On 12/11/05 20:29, in article ,
    "Bob Hairgrove" <> wrote:


    > As long as you keep to the same environment (i.e. same compiler, etc.)
    > there's nothing inherent about the STL which would preclude making a
    > shared library with components which use it, as long as the clients
    > using the shared library are also compiled with the same compiler.


    That¹s what I thought, but I have a wild aspiration to possibly license our
    framework to existing clients. In that case, we can't really rely on them
    using a specific compiler. (Perhaps it's far too wild!)

    > It all depends on how it is used, of course. You have to be
    > particularly careful with memory management issues when using shared
    > libraries, i.e. creating an object with "new" in one module and
    > destroying it with "delete" in a different module is definitely
    > something to avoid. The only way this can possibly work is if ALL
    > executables and libraries involved use the same C runtime library. And
    > the only way this would work is to link the CRT dynamically.


    Absolutely. And I have been bitten with this before. Once bitten, and all
    that!

    > A good (and important) design pattern for this problem is the
    > "abstract factory". You would typically do the creation and
    > destruction of objects in the same factory class, exposing
    > Factory::Create() and Factory::Destroy() functions, instead of relying
    > on the clients to call new and delete.


    Nice idea. And by making making constructors private, I can ensure the user
    will always need to call the Create and Destroy methods?


    Thanks very much.

    --
    Regards,
    Steve

    "...which means he created the heaven and the earth... in the DARK! How good
    is that?"
    Steve, Nov 12, 2005
    #3
  4. Steve

    Ian Guest

    Steve wrote:
    > Hi,
    >
    > We have an application framework library that gets statically linked to any
    > applications we produce. (Windows apps, but I don't think that matters
    > here).
    >
    > The framework is based heavily on the STL and the API uses many STL
    > constructs. Because of the static linking, and the fact that both app and
    > framework are built by the same compiler, we don't have any problems.
    >
    > Now somebody has suggested we make the framework a shared library.
    >
    > Of course, this probably means a big re-write is on the cards, and I am
    > aware that there can be issues if std::strings and other STL templated
    > classes are exposed on a shared library API.
    >

    What C++ (rather than platform) issues do you foresee?

    > Has anyone here had to tackle this problem? Any advice would be most
    > welcome. (Is there a common design pattern one could follow?)
    >

    Many times and I've never had any issues.

    > I guess this is the reason why C++ libraries like QT and xerces provide
    > their OWN classes instead of using STL, right? :)
    >

    No, they just pre-date the standard library.

    Ian
    Ian, Nov 12, 2005
    #4
  5. Steve wrote:
    > We have an application framework library that gets statically linked to any
    > applications we produce. (Windows apps, but I don't think that matters
    > here).
    >
    > The framework is based heavily on the STL and the API uses many STL
    > constructs. Because of the static linking, and the fact that both app and
    > framework are built by the same compiler, we don't have any problems.
    >
    > Now somebody has suggested we make the framework a shared library.
    >
    > Of course, this probably means a big re-write is on the cards, and I am
    > aware that there can be issues if std::strings and other STL templated
    > classes are exposed on a shared library API.


    The most simple approach is to link to the dynamic CRT library. This way you will only
    have one heap, and this would save you from allocating in one heap (in main application)
    and freeing in another heap (in your shared library), or vice verse.

    > Has anyone here had to tackle this problem? Any advice would be most
    > welcome. (Is there a common design pattern one could follow?)

    Another thing you must be aware of is the problem of "multiple singletons". If you have a
    header file with something like
    template<class T> struct A { static MySingleton singleton; };
    MySingleton A::singleton;
    and you include this header file both, in your shared library and in your main executable,
    then you will get two instances of this singleton, one in the shared library, and another
    one in the main executable. This wouldn't happen if you had a static library.

    > I guess this is the reason why C++ libraries like QT and xerces provide
    > their OWN classes instead of using STL, right? :)

    No. They were written before the standard came out. Actually, afaik QT 4.0 uses STL.

    --

    Valentin Samko - http://www.valentinsamko.com
    Valentin Samko, Nov 12, 2005
    #5
  6. Steve

    Steve Guest

    On 12/11/05 21:13, in article ,
    "Ian" <> wrote:

    > Steve wrote:
    >> Hi,
    >>
    >> We have an application framework library that gets statically linked to any
    >> applications we produce. (Windows apps, but I don't think that matters
    >> here).
    >>
    >> The framework is based heavily on the STL and the API uses many STL
    >> constructs. Because of the static linking, and the fact that both app and
    >> framework are built by the same compiler, we don't have any problems.
    >>
    >> Now somebody has suggested we make the framework a shared library.
    >>
    >> Of course, this probably means a big re-write is on the cards, and I am
    >> aware that there can be issues if std::strings and other STL templated
    >> classes are exposed on a shared library API.
    >>

    > What C++ (rather than platform) issues do you foresee?


    The implementation of std::string [as one example] might be, or, is probably
    different between compilers - for example, GCC and Visual Studio.

    Say the library was compiled with Visual Studio, then the API was used
    within a gcc-compiled application, and the API had the following function:

    void DoSomething( const std::string& );

    GCC would pass a reference to it's own std::string object. The
    implementation of the function (compiled under Visual Studio) is still
    expecting a std::string, but its internals are likely to be completely
    different.

    >
    >> Has anyone here had to tackle this problem? Any advice would be most
    >> welcome. (Is there a common design pattern one could follow?)
    >>

    > Many times and I've never had any issues.


    But are the libraries built with one compiler, then used in an application
    built with a different one?

    As I said in my reply to Bob Hairgrove, this may be just a wild aspiration I
    have. I could probably live without this requirement for now!

    >> I guess this is the reason why C++ libraries like QT and xerces provide
    >> their OWN classes instead of using STL, right? :)
    >>

    > No, they just pre-date the standard library.


    Are you sure? I can't confirm QT, but the initial beta release of xerces was
    in November 1999.

    --
    Regards,
    Steve

    "...which means he created the heaven and the earth... in the DARK! How good
    is that?"
    Steve, Nov 12, 2005
    #6
  7. Steve

    Ian Guest

    Steve wrote:
    >>
    >>What C++ (rather than platform) issues do you foresee?

    >
    >
    > The implementation of std::string [as one example] might be, or, is probably
    > different between compilers - for example, GCC and Visual Studio.
    >
    > Say the library was compiled with Visual Studio, then the API was used
    > within a gcc-compiled application, and the API had the following function:
    >
    > void DoSomething( const std::string& );
    >
    > GCC would pass a reference to it's own std::string object. The
    > implementation of the function (compiled under Visual Studio) is still
    > expecting a std::string, but its internals are likely to be completely
    > different.
    >

    Ah, I missed you point. No, you cant mix C++ objects or libraries built
    with different compilers. Unless you only interface through extern "C"
    functions.


    >>
    >>No, they just pre-date the standard library.

    >
    >
    > Are you sure? I can't confirm QT, but the initial beta release of xerces was
    > in November 1999.
    >

    Wasn't xerces an internal IBM project way before it was part of Apache?

    Ian
    Ian, Nov 12, 2005
    #7
  8. Ian wrote:
    >> GCC would pass a reference to it's own std::string object. The
    >> implementation of the function (compiled under Visual Studio) is still
    >> expecting a std::string, but its internals are likely to be completely
    >> different.
    >>

    > Ah, I missed you point. No, you cant mix C++ objects or libraries built
    > with different compilers. Unless you only interface through extern "C"
    > functions.


    Moreover, you can not mix objects built with the same compiler but when optimisation
    settings differ in specific ways, and this is compiler dependent. The first problem would
    be padding of class data members.

    --

    Valentin Samko - http://www.valentinsamko.com
    Valentin Samko, Nov 12, 2005
    #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. Dave Neary

    JVM and shared libraries

    Dave Neary, Jun 9, 2004, in forum: Java
    Replies:
    13
    Views:
    1,195
  2. barcaroller
    Replies:
    1
    Views:
    311
    Ian Collins
    Jun 12, 2007
  3. Replies:
    0
    Views:
    281
  4. Replies:
    0
    Views:
    764
  5. Alpha Blue

    RUBYLIB and shared libraries

    Alpha Blue, Feb 2, 2010, in forum: Ruby
    Replies:
    2
    Views:
    115
    Alpha Blue
    Feb 2, 2010
Loading...

Share This Page