CODEWITHSUNDEEP
c++design-patternsstlshared-libraries
void.pointer
void.pointer

Reputation: 26315

C++ interface design around shared library boundaries

Suppose I have two projects. One is an application and the other is a shared library that contains common, reusable code that could be used by more than just this application.

My application uses STL, and my shared library also uses STL. The first problem here is that my shared library is using STL. If I ever build a newer version of STL into my application but I do not rebuild my shared library because it is not necessary, then we will have compatibility issues right away.

My first thought to solve this issue is to not use STL at all in the interface to the shared library classes. Suppose we have a function in my library that takes a string and does something with it. I would make the function prototype look like:

void DoStuffWithStrings( char const* str );

instead of:

void DoStuffWithStrings( std::string const& str );

For strings this will probably be OK between different versions of STL, but the downside is that we are going from std::string, to char*, and back to std::string, which seems like it causes performance issues.

Is the boxing/unboxing of raw types to their STL counterparts recommended? This becomes even worse when we try to do this to a std::list, since there really is no "raw type" I am aware of that we could easily pass it as without doing some sort of O(n) or similar operation.

What designs work best in this scenario? What are the pros/cons of each?

Upvotes: 9

Views: 3105

Answers (4)

Bjorn
Bjorn

Reputation: 961

Another problem can come up if the library uses a different heap than the application. If this is the case or could be the case, make sure library owns/manages its own memory. Multiple heaps can be an issue when the library uses a different c-library and therefore a different malloc/free and therefore a different heap. http://msdn.microsoft.com/en-us/library/ms810466.aspx

Upvotes: 2

han
han

Reputation: 755

Surely the standard C++ library should be considered a part of the C++ ABI just as much as the virtual table layout or name mangling scheme. Besides, any incompatible changes in the ABI are more likely to affect obscure corner cases rather than the layout of std::vector. In other words: if you're going to make a C++ library, feel free to use standard C++ classes.

Upvotes: 2

umlcat
umlcat

Reputation: 4143

Many A.P.I. and Shared Libraries use "opaque" or generic pointers as arguments in functions, in order to avoid differences among versions.

// this:
int MyFunc(char* Param1, int Param2, bool Param3);

// into this:
struct MyParams
{
  char* Param1;
  int Param2;
  bool Param3;
}

// "Params" its really "struct MyParams*"
int MyFunc(void* Params);

And sometimes if a Shared Library function has several arguments, they replaced to a pointer, taht is expected to be a pointer to an array or structure or even a class.

It depends how are you going to work with your library, since many libraries are used like plain C, even if you are using C++.

Upvotes: 0

stijn
stijn

Reputation: 35901

One of the pros of the const char* approach is that your library will also be callable from C, and hence from a lot of other laguages interfacing to C as well (pretty much everything out there). This alone is a very interesting selling point.

However, if you write and maintain both libraries, and they will be used in C++ only (say for the next 5 years), I would not go through the hassle of converting everything. std::string is one thing, std::vector or std::map won't convert as nicely. Apart from that, how many times do you move to another STL implementation? And in those cases, are you really going to 'forget' to rebuild your shared library as well? Also, you can still write/generate C style wrappers afterwards if really needed.

Conclusion (biased towards my experiences with this matter): if you don't need C, go with stl.

Upvotes: 2

Related Questions