当通过C＃调用C ++ DLL的导出类时，该类的C风格字符串成员在一个导出函数中是正常的，但在另一个导出函数中则没有

Question

C++ console calls DLL OK, but not C#.

In the exported function setInputs , the const char* -type public member of class object is set OK, but in the exported function run , it becomes some meaningless characters.

exported DLL:

namespace{
    CLASS*CLASS_Ptr_Object=new CLASS();
    }

extern "C" __declspec(dllexport)
void setInputs(char*char_Ptr_Model,int int_Type){
        CLASS_Ptr_Object->m_char_Ptr_Input_Model=char_Ptr_Model;//when I print the public member m_char_Ptr_Input_Model, I see it is OK here
        CLASS_Ptr_Object->m_int_Type=int_Type;//int and double types are always OK
}

extern "C" __declspec(dllexport)
void run(){
    CLASS_Ptr_Object->run();//when I print the public member m_char_Ptr_Input_Model, I observe it has become some meaningless characters, although it was OK in previous exported function
}

how the public member is defined in header file:

class CLASS
    {

    //...

    public:
        const char*m_char_Ptr_Input_Model;
    };

Invoke in C#:

[DllImport(@"DLL.dll", EntryPoint = "setInputs")]
        public static extern setInputs(
            [In, Out, MarshalAs(UnmanagedType.LPStr)]string char_Ptr_Model
            , [In, Out, MarshalAs(UnmanagedType.I4)]int int_Type
             );

 [DllImport(@"DLL.dll", EntryPoint = "run")]
 public static extern run();

Answer 1

The content of the character buffer that supplied by the C# marshaller is only valid for the duration of the call to setInputs . As soon as setInputs finishes, referring to that buffer is invalid.

The marshaller creates a temporary buffer to hold the character array, converts from the UTF-16 .net string to an 8 bit string. And then calls setInputs passing the address of the temporary buffer. When setInputs returns, the temporary buffer is destroyed. But you've held on to the address of that buffer and now you have a pointer to who knows what.

You will need to take a copy of the string. The simplest way is to declare the member to be of type std::string and use the assignment operator that accepts a const char* assignment source.

Answer 2

The problem with your exported DLL function that handles strings is that you're relying that the calling language (in your case C#) handles pointers in the same manner as C++. As the answer that David Heffeman has given, you can't assume that the calling language uses the same semantics as a C++ program would use.

If the calling program were C++, and if the pointer points to the string after the DLL call, then of course you will see that the DLL pointer also points to the string. But strings in other languages, and marshaling of such strings to DLL functions can and will work differently than the "simple" C++ model.

Assuming we're not talking about COM, but just generic string handling for non-COM DLL's, if you look at how a typical Windows API function handles strings, it uses one of the following methods:

For accepting strings:

An LPCTSTR is usually the parameter type, and the Windows API function takes the pointer provided and copies the contents of the buffer to an internal buffer (if that's the purpose of the function). This could mean storing the value in a char array, or as the answer suggested, stored in a std::string or some other container internal to the DLL. Thus, when the function returns, the pointer value that was originally passed is no longer referred to -- the data is intact within the DLL.

For returning strings:

An LPTSTR is passed as a parameter, along with a length argument denoting the maximum number of characters to copy from the Windows API function to the buffer. Another variant is that the API function documents how big the buffer should be, and the caller has to ensure that the buffer is big enough. The DLL function then copies the data to the buffer and returns.

In none of the above scenarios does the DLL store the pointer to the buffer.