DLLs and Standard Library

[Golden Lizard]

If I understood it right it's a pain in the @$$ to import classes from the standard libraries due to a large amount of dependencies. So my question is, should I even try to import STL containers or rather make my own template classes for general proposes and import them in the DLLs I need.

[kbw]

If I understood it right it's a pain ... to import classes

Wrong. You can use classes from libraries.

So my question is, should I even try to import STL containers

Templates tend to be inlined, and most of the STL is. You are expected to use the standard library rather than write your own version.

[andywestken]

The main danger of using C++ linkage between modules is due to memory allocation. If you pass a std::string or std::vector from one module to another, they're both got to be using the the same standard library. This means the same version (even build!) and same build target (debug or release) or memory management will be stuffed.

Furthermore, debug containers often have additional member for validation purposes, so the class layout of the debug version of container could be different to that of the release version.

As long as you link all of your components against exactly the same C++ runtime libraries it won't be a problem. So if you're developing a set of components to be deployed at the same time, I wouldn't wory.

But if you want to write a library that is future proofed against changes in the C++ runtime, then write DLLs that export C functions and be careful with how you handle memory.

e.g. the OpenLDAP API's ldap_get_values() function (exported by openldap.dll) returns allocated memory which must be freed by passing it back to the DLL's ldap_value_free() function, so the same memory allocate frees it that allocated it. You can't just use free() or delete.

Note this isn't a template/non-template issue (you can't import a template, only the instantation of a template.) It's a C++ linkage issue.