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

前端 未结 2 727
青春惊慌失措
青春惊慌失措 2021-02-18 20:50

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

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

public:
    std::strin         


        
相关标签:
2条回答
  • 2021-02-18 21:33

    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.

    0 讨论(0)
  • 2021-02-18 21:44

    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.

    0 讨论(0)
提交回复
热议问题