We have a small group on our program redesigning an API that is to be used by 3rd party developers to create a shared library that our system will use. The current API interface is extremely old, very cumbersome to use, and very C-like. The goal is to create a more C++-like interface, make it much easier to use, and add some additional functionality. The library delivered by the 3rd party developers adhering to the new API will be a shared object (.so file) used by our system on a Redhat Linux platform.

An individual on our team recently pointed out that the API should not use any STL type arguments, pointing out that “it would be in violation of the API (Application Binary I/F) spec that compilers must follow”. He further argued that the only way this would work would be if the library and executables are compiled and linked exactly the same so all template implementations are the same across the linked modules. Since we do not have control over what compiler versions will be used, or what compiler flags will be used by the 3rd party developers, it cannot be guaranteed that the library will work.

I’ve since done some light reading on the internet and have not come to a definitive conclusion as to whether these statements are accurate. It seems that there is much discrepancy (or confusion) as to whether or not the API is designed in a Windows environment (which uses DLL’s) or a Linux environment (which uses SO’s).

So, is it true that defining a shared object API that passes STL arguments to and from its interface is not a smart design and may cause problems? Or, is this just a problem for MS and how their DLL’s are laid out?

Any insight would be greatly appreciated. Thanks.