Re: STL compatibility in MS VS 2003/2005
Jenny wrote:
Hello
We have developed a dll in MS Visual Studio .Net 2003 using unmanaged C++.
The interface of this dll is std. Internally the dll is mixed with C/C++/MFC
libraries. The dll runs well with a testing stub which imports this dll. Of
course, the testing stub is developed in the same platform and IDE.
When we ship this dll to our customer side, the customer's application is
developed in MS Visual Studio .NET 2005. They have problem to access all
std::string returned from our exported dll interface. It does not matter that
std::string is returned by value or reference. Access violation is generated
(bad pointer returned within std::string).
Strangely enough, if std::string is embedded within a struct and returned
from the dll interface, our customers release version application works with
our dll, but not debug version.
So far, we tried to return char *, std::string by value, std::string by
reference and struct {std::string xx,} in the dll interface. Nothing works
completely in both release and debug version.
Any help is very appreciated.
The STLs of 2003 and 2005 are not binary compatible - you cannot import
a 2003 DLL that exports a function using std::string or any other
std::container and use it in VC2005 (at least not in a documented,
reliable way - you've apparently found some specific combinations that
don't crash, but may be corrupting data in some other way).
If your users are using compilers other than the one you developed on,
you have a few options:
1. Use COM, thus using BSTR instead.
2. Export either a C++ API using no std::containers, or even a C API.
Note that the memory for the char* must be deallocated by the same
module that allocated the memory (since the modules will be using
different CRT heaps), so your DLL will need to export a "free memory"
function of some kind, or it should model itself on most C libraries,
where you pass in the buffer rather than it being returned (thus the DLL
doesn't do any memory allocation of user buffers).
3. (An improvement on 2) Do the above, but additionally provide a source
code library that the user can add to their code that wraps up the usage
of the API in nice C++ classes, using standard containers. Since this
code is then compiled by their compiler, no compatibility problems exist.
Tom