"Ferdinand Prantl"
The second option (as Holger says) is to make a simple facade to the c++ library (all you might use), which will not have templates (here smart pointers) on the interface, and to use this facade instead.
Did I say that? Anyway, I absolutely agree. I just want to point out that IMHO the best solution is to _not_ export instrusive_ptr_add_ref and _release. If you do new and delete are called from different modules which works only if the same CRT instance is used. And that works only if both link against the exact same version of the CRT dll (that is both linking against a static CRT still yields to instances => two heaps => error). While we're at it, it's almost always a bad thing to export classes or functions that rely on classes from a DLL. DLLs are a run time concept. They don't have any clue which version of the compiler a consumer is built with. E.g. say you export a function void foo( std::string& s ) { s = "Hello World!"; } The DLL is built with the version A of the compiler and STL and the consuming application is built with version B. There is no guarantee for a binary compatibility between the two version. And indeed the code above will break if version 6 & 7 of VC are used (The former used a COW scheme while the second uses a short string optimization). Also, do note that the DLL CRT now supports side by side sharing. While I am in rant mode the catch(...) thing is also a very bad idea in VC. This currently catches (this will be fixed in 8.0) structured exception that are not C++ exception. That way serious error conditions are silently ignored. -hg