How to decide _ITERATOR_DEBUG_LEVEL?

Question

0.00/5 (No votes)

See more:

Hello!

I have build Lib. in Release mode. After that I use it in my project under Debug mode and I'm getting error:

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in .obj
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in

The problem that I can't change options of Lib. and I have to build it under Release.

Is it possible to cheat visual studio and use release Lib in project with Debug mode?

Posted 16-Dec-13 6:28am

thomas_wingfield

Add a Solution

Comments

Sergey Alexandrovich Kryukov 16-Dec-13 17:47pm

Visual Studio does not build anything to cheat it. It is just the IDE... If you have only one version of .obj/.lib, not separate versions for different configurations (check it up!), use level of the library...
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

H.Brydon · Accepted Answer · 2013-12-16T16:10:00

You can mix debug and release linkage only under a short list of circumstances:
- If you cross the DLL boundary using "plain old data"/POD types in all method parameters.
- If you have any classes that contain only POD data.
- If you pass only const items and receive POD return values.
- If you deal with any class data across the boundary, then both sides of the boundary must see the class exactly the same way (eg. nothing #ifdef'd out in release build, alignment the same, ...)
- If you call an API across the DLL boundary that has class data, then all memory management must be done in one place or the other. If an object is created in the DLL, it must be deleted there as well.
- Several other possibilities that I haven't identified off the top of my head...

Note the following examples:
- CString and std::string are not (necessarily) safe between debug/release or between different builds of the compiler. Sad but true, you need to use "char*" and "const char*" in OOPS code.
- Any Microsoft struct or class should be fine between debug/release and different builds. Make sure that you correctly set the size field in any structs.