Mixing debug and release library/binary - bad practice?

Question

Is it a bad practice to use a release version of 3rd party library in debug binary?

I am using a 3rd party library and compiled a release .lib library. My exe is in

Answer 1

Mixing debug and release code is bad practice. The problem is that the different versions can depend on different fundamental parts of the C++ runtime library, such as how memory is allocated, structures for things like iterators might be different, extra code could be generated to perform operations (e.g. checked iterators).

It's the same as mixing library files built with any other different settings. Imagine a case where a header file contains a structure that is used by both application and library. The library is built with structure packing and alignment set to one value and the application built with another. There are no guarantees that passing the structure from the application into the library will work since they could vary in size and member positions.

Is it possible to build your 3rd party libraries as DLLs? Assuming the interface to any functions is cleaner and does not try to pass any STL objects you will be able to mix a debug application with release DLLs without problems.

Answer 2

Mixing debug and release library/binary is good and very useful practice.

Debugging a large solution (100+ projects as an example) typically is not fast or even could not be possible at all (for an example when not all projects can be built in debug). Previous commentators wrote that debug/release binary could have different alignment or another staff. It's not true. All linking parameters are same in debug and release binaries because they depends on the same architecture.

You have to remove all optimizations (/Od) from the selected project. Then assign a release c++ runtime.

The issue came because you have defined _DEBUG in the project. Remove the macro from the definitions (Project->Properties->Preprocessor->Preprocessor Definitions).

If the macro isn't in the Preprocessor Definitions, then you have to add it in "UndefinePreprocessorDefinitions".

Answer 3

The fact that it doesn't compile should be sufficient to prove it's bad practice.

Regarding maintaining separate builds - you don't need to do that. Here's a workaround that previously worked for me:

#ifdef _DEBUG
#define DEBUG_WAS_DEFINED
#undef _DEBUG
#endif

#include <culprit>

#ifdef DEBUG_WAS_DEFINED
#define _DEBUG
#endif

Let me know if this works for you.