My question is related to exporting a C++ class with STL inside. For example:
class __declspec(dllexport) Hello
{
std::string name;
public:
std::strin
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.