Exporting STL class from DLL - why is there no warning from the return type?

Question

My question is related to exporting a C++ class with STL inside. For example:

class __declspec(dllexport) Hello
{
    std::string   name;

public:
    std::string&  getName();
    void          setName(const std::string& name);
}

Various articles seems to indicate that this is very bad, which is quite understandable. Everything must be compiled with the same compiler settings and CRT version. Otherwise everything will crash and burn.

Question:

What I don't understand is why only data members seem to have an issue. With the below code, I get: "C4251: needs to have dll-interface to be used by clients of class"; which is apparently fixed by exporting the instantiated std::string:

struct __declspec(dllexport) SomeClass
{
    // Removes the warning?
    // http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html
    //   template class __declspec(dllexport) std::string;

    std::string name;  // Compiler balks at this
}

And the fixed version is:

// Export the instantiations of allocator and basic_string
template class __declspec(dllexport) std::allocator<char>;
template class __declspec(dllexport) std::basic_string<char, std::char_traits<char>, std::allocator<char> >;

struct __declspec(dllexport) SomeClass
{
    std::string name;  // No more balking!
}

(This will give LNK2005 "basic_string already defined" when you try to use the DLL, meaning you have to not link in the CRT on the client - so it ends up using the instantiation in the DLL).

Return types and arguments seem to have no problem with the STL, and do not receive the same treatment data members get from the compiler.

// No exporting required?
struct __declspec(dllexport) SomeOtherClass
{
    std::string  doSomething1();                       // No problemo
    void         doSomething2(const std::string& s);   // No problemo
}

Additional Info (Question is above)

In both:

class A {
    std::string foo() { return std::string(); }
    // std::string& foo(); gives the same result!
    // std::string* foo(); also gives the same result!
}

class B {
    std::string a;
}

Neither seem to export std::basic_string or std::allocator. Rather, they only export the members/functions of the class.

However the fixed version mentioned in the question exports both basic_string and allocator.

Answer 1

Various articles seems to indicate that this is very bad

Yes, it can be. And your project settings are going to get you into the kind of trouble they are warning about. Exposing C++ objects by value requires the client of your DLL to use the same CRT so that objects that are created in the DLL can be safely destroyed by the client app. And the other way around. Which requires that these modules use the same heap.

And your project settings prevent that from being possible, the gist of the compiler warning. You must specify the shared version of the CRT so that all modules load the one-and-only implementation of the CRT.

Fix that with Project + Properties, C/C++, Code Generation, Runtime library setting. You have it now at /MT, it must be /MD. Change this for all modules and all configurations.

Answer 2

This boils down to how certain things get built.

When the compiler sees

__declspec(dllimport)    std::string f();
// ...

{
  std::string tmp = f();
}

It must figure out what to call, and where to get it from. So in this case :

std::string tmp; => sizeof( std::string ), new (__stack_addr) std::string;
tmp = f();       => call f(), operator=( std::string )

But because it sees the complete implementation of std::string it can just use a new instance of the the according template. So it can just instantiate the template functions of std::string and call it a day, and leave the function coalescing to the linker stage, where the linker tries to figure out which functions it can fold into just one. The only unknown function is f() which the compiler must import from the dll itself. (It's marked external for him).

Members are a bigger problem for the compiler. It has to know the according functions to export (constructor,copy-constructor,assignment-operator,destructor call) and when you mark a class as 'dllexport', it must export/import every single one of them. You can export explicitly only certain parts of your class, by declaring only the necessary functions as dllexport (ctor/dtor) and disallow e.g. copying. This way, you don't have to export everything.

One note about std::string is, that its size/contents changed between compiler versions, so that you never can safely copy a std::string between compiler versions. (E.g. in VC6 a string was 3 pointers large, currently it's 16 bytes + size + sizeof allocator, which I think got optimized away in VS2012). You never should use std::string objects in your interface. You may create a dll-exported string implementation that converts on the caller site into a std::string by using non-exported inline functions.