CODEWITHSUNDEEP
c++visual-c++std
user667967
user667967

Reputation: 648

std objects passed between different DLLs

I believe that the source of my problem lies in the fact that I am dependent on a shared library which was compiled with Visual C++ 2008, but other libraries were compiled with Visual C++ 2010. (Currently, I am using Visual C++ 2010 myself.)

Those libraries heavily rely on the std. Some functions in the DLLs require std-objects as arguments and return std-objects (std::string for example).

Is it possible to make those DLLs compatible with my executable even though the std library versions differ?

There should be a standard solution to this kind of issue but I couldn't find it. Can you please point me in the right direction?

Upvotes: 1

Views: 484

Answers (2)

Adrian McCarthy
Adrian McCarthy

Reputation: 48019

I've heard Stephan T. Lavavej, on several occasions, say that binary compatibility of C++ objects is not guaranteed across major versions of the compiler, so passing STL objects to an API in a component built with another version is likely to be problematic. Note that many STL objects are templates and are thus heavily inlined. If you pass STL objects across a boundary, then that inlining may be happening on both sides. If you compile the code on either side of the boundary with different implementations of the STL, you're likely to have problems.

These kinds of problems are what things like COM were invented for: a safe way to pass objects between components.

Barring changing everything to COM, your best bet is to make sure all the libraries you share C++ objects with are built with the same version of the same compiler. If you cannot rebuild those DLLs with the newer compiler, you'll have to compile your code with the older compiler.

Upvotes: 1

Synxis
Synxis

Reputation: 9388

You might be able to use std objects from different versions of msvc, I don't know if there is a binary compatibility.

You can search for object destruction, that often cause crashes. An object created in a specific module must be deleted in that specific module, for the same CRT to handle it. If this condition is not met, the behavior is undefined (likely to be a crash)

The safest solution is to encapsulate all objects in interfaces, see How to export C++ classes from dlls.

Upvotes: 1

Related Questions