dll在调试模式下，在发布模式下调用程序（反之亦然）

Question

I'm writing a small C++ program that tests C dlls, containing some functions. Those dlls exist in a debug version and a release version and I would like to load them both with the same program and compare them with a previous version.

The problem is, when I compile my program with release config, it can only use the dlls that are also release, and when I compile the program using debug config it can only use dlls that are also debug.

I load the dlls/functions using LoadLibrary and GetProcAddress functions.

There are two types of functions: void type1(int&) and void type2(vector<string>*) . Type 1 works fine no matter the configuration. But type 2 only works when the configuration matches.

Code:

typedef void(*GetNames)(vector<string>*);
GetNames get_var_names = (*GetNames)GetProcAddress(dll,"get_var_names");
vector<string> var_names;
get_var_names(&var_names);

The last line is where the program fails with an error like "0xC0000005: Access violation reading location 0xbaadf008." if the configuration of calling program and dll don't match. The error is a reading violation when program is release and dll is debug, but a writing violation when program is debug and dll is release.

What the function is supposed to do is just call push_back("x") a few times with different strings.

It doesn't seem to be totally impossible to use a debug dll in a release config program or all the functions of type 1 also wouldn't work, so it seems to have something to do with vector or string class.

Anyone have any idea how to solve this or is using two executables with different configurations my only choice?

Answer 1

Many (if not all) STL classes use different layout for DEBUG-builds. Therefor you cannot use such a DEBUG-compiled class from a dll (like std::string and std::vector) in a RELEASE-build of a program and vice versa.

Should avoid using STL-types/class in your interface of your dll's and use build-in types instead. In that case you'll never have those issues.

BTW: I am talking about MSVC++ of course (other compilers I don't know of).