Passing std::string in a library API

We are currently building an API for a certain library. Part of the interface requires the library to get and return to the user classes such as vector and string.

When trying to simulate use of the library in a simple scenario, in debug mode the system crush when delivering a string as an input.

I believe there is a different representation of the string class in debug or release mode. Then our library assumes to receive a certain representation, read a data member incorrectly and crush along the way. So what is the best way method to transferring STL objects in an API. The target OS is windows XP compiled开发者_StackOverflow中文版 with MSVC 8, although the library user will use windows their compiler might (and probably will) be different Ideas we had so far:

1. Change string to char* - But then developers might be baffled with the responsibility of releasing the memory.
2. Use our own version of String – I don't want to develop another private implementation of string.
3. Release to the user debug version and release version.
4. Ask people on Stack overflow for some option we miss or don’t understand, or just hear from their experience - done.

It's not unreasonable at all to make people link against debug in debug mode, and release in release mode. That is how virtually every library does it. Even huge projects like DirectX release debug compiles of their binaries. #3 is a perfectly reasonable option/solution.

You should avoid passing STL objects between different binary modules.

For string, you have to rely on const char* for read only parameter and char*, <buffer size> for input parameters...

For vectors, it could be a bit more difficult especially if you have to change the content of the vector...

About your ideas:

1. You are right, but the convention usually is that you can't store the passed pointer (you have to do your local copy).
2. At the end you would have the same issue unless you have the same binary representation on debug and release version of your implementation.
3. This may be harmful if you use different versions/implementation of STL in the two binary modules (unless you are sure that the library user will use the same STL).