C++ interface design around shared library boundaries

Question

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?

Answer 1

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.