2

My executable makes calls to a number of DLLs, that i wrote myself. According to 3rd party C++ libs used by these DLLs i can not freely choose compiler settings for all DLLs. Therefore in some DLLs _ITERATOR_DEBUG_LEVEL is set to 2 (default in the debug version), but in my executable _ITERATOR_DEBUG_LEVEL is set to 0, according to serious performance problems.

When i now pass a std::string to the DLL, the application crashes, as soon as the DLL tries to copy it to a local std::string obj, as the memory layout of the string object in the DLL is different from that in my executable. So far i work around this by passing C-strings. I even wrote a small class that converts a std::map<std::string, int> to and from a temporary representation in C-Data in order to pass sich data from and to the DLL. This works.

How can i overcome this problem? I want to pass more different classes and containers, and for several reasons i do not want to work with _ITERATOR_DEBUG_LEVEL = 2.

RED SOFT ADAIR
  • 12,032
  • 10
  • 54
  • 92
  • Not at all - no stl does not mean no OO. You can make an abstract interface/adapter with classes that contain no data members - only pure virtual methods. Here I found an interesting article about that: [The Code Project: Export C++ classes from a DLL](http://www.codeproject.com/KB/cpp/howto_export_cpp_classes.aspx#CppMatureApproach) – MacGucky Mar 17 '11 at 14:37
  • No, as a customer you should **demand** to have the 3rd party libraries compiled in a usable version. Or be allowed to recompile yourself. This is not a language problem, this is a business problem. Who sells unusable libraries for long?! – Bo Persson Mar 17 '11 at 14:40

3 Answers3

4

The problem is that std::string and other containers are template classes. They are generated at compilation time for each binary, so in your case they are generated differently. You can say it's not the same objects.

To fix this, you have several solutions, but they are all following the same rule of thumb : don't expose any template code in your header code shared between binaries.

You could create specific interfaces only for this purpose, or just make sure your headers don't expose template types and functions. You can use those template types inside your binaries, but just don't expose them to other binaries.

std::string in interfaces can be replaced by const char * . You can still use std::string in your systems, just ask for const char * in interfaces and use std::string::c_str() to expose your data.

For maps and other containers you'll have to provide functions that allow external code to manipulate the internal map. Like "Find( const char* key ); ".

The main problem will be with template members of your exposed classes. A way to fix this is to use the PImpl idiom : create (or generate) an API, headers, that just expose what can be done with your binaries, and then make sure that API have pointers to the real objects inside your binaries. The API will be used outside but inside your library you can code with whatever you want. DirectX API and other OS API are done that way.

Klaim
  • 67,274
  • 36
  • 133
  • 188
  • What if your library has classes that are meant to be derived from? – phandinhlan Jun 17 '15 at 08:33
  • @phandinhlan What would be the problem in this case? If you think about providing access to internal members, then just use protected accessors functions to these members which would be stored in the impl. – Klaim Jun 17 '15 at 12:49
3

It is not recommended to use an c++ interface with complex types (stl...) with 3rd party libs, if you get them only as binary or need special settings for compile which are different from your settings.

As you wrote - the implementation could be different with the same compiler depending on your settings and with different compilers the situation gets even worse.

If possible compile the 3rd party lib with your compiler and your settings.

If that's not possible you may write an wrapper-DLL which is compiled with the same compiler and same settings than the 3rd party lib and provides an C-Data interface for you. In your project you may write another wrapper-class so you can make your function-calls with STL-Objects and get them converted and transfered "in background".

MacGucky
  • 2,494
  • 17
  • 17
2

My own experience with flags like _SECURE_SCL and _ITERATOR_DEBUG_LEVEL, is that they must be consistent if you attempt to pass a stl object accross dll boudaries. However I think you can pass a stl object to a dll which has a smaller _ITERATOR_DEBUG_LEVEL since you can probably give a stl object instantiated in a debug dll to a dll compiled in release mode.

EDIT 07/04/2011 Apparently Visual Studio 2010 provides some niceties to detect mismatches between ITERATOR_DEBUG_LEVEL. I have not watch the video yet.

http://blogs.msdn.com/b/vcblog/archive/2011/04/05/10150198.aspx

fff
  • 66
  • 3