Question

Short question.

I just got a dll I’m supposed to interface with.
Dll uses crt from msvcr90D.dll (notice D), and returns std::strings, std::lists, and boost::shared_ptr. Operator new/delete is not overloaded anywhere.

I assume crt mixup (msvcr90.dll in release build, or if one of components is rebuilt with newer crt, etc) is bound to cause problems eventually, and dll should be rewritten to avoid returning anything that could possibly call new/delete (i.e. anything that could call delete in my code on a block of memory that was allocated (possibly with different crt) in dll).

Am I right or not?

Answer 1

The main thing to keep in mind is that dlls contain code and not memory. Memory allocated belongs to the process(1). When you instantiate an object in your process, you invoke the constructor code. During that object’s lifetime you will invoke other pieces of code(methods) to work on that object’s memory. Then when the object is going away the destructor code is invoked.

STL Templates are not explicitly exported from the dll. The code is statically linked into each dll. So when std::string s is created in a.dll and passed to b.dll, each dll will have two different instances of the string::copy method. copy called in a.dll invokes a.dll’s copy method… If we are working with s in b.dll and call copy, the copy method in b.dll will be invoked.

This is why in Simon’s answer he says:

Bad things will happen unless you can
always guarantee that your entire set
of binaries is all built with the same
toolchain.

because if for some reason, string s’s copy differs between a.dll and b.dll, weird things will happen. Even worse if string itself is different between a.dll and b.dll, and the destructor in one knows to clean extra memory that the other ignores… you can have difficult to track down memory leaks. Maybe even worse… a.dll might have been built against a completely different version of the STL (ie STLPort) while b.dll is built using Microsoft’s STL implementation.

So what should you do? Where we work, we have strict control over the toolchain and build settings for each dll. So when we develop internal dll’s, we freely transfer STL templates around. We still have problems that on rare occasion crop up because someone didn’t correctly setup their project. However we find the convenience of the STL worth the occasional problem that crops up.

For exposing dlls to 3rd parties, that’s another story entirely. Unless you want to strictly require specific build settings from clients, you’ll want to avoid exporting STL templates. I don’t recommend strictly enforcing your clients to have specific build settings… they may have another 3rd party tool that expects you to use completely opposite build settings.

(1) Yes I know static and locals are instantiated/deleted on dll load/unload.