Unable to add defines to boost build

Question

I am trying to build a debug build of boost serialization/filesystem/system using boost buildsystem. Here is what I use:

  b2 serialization filesystem system variant=debug link=static threading=multi
  runtimelink=static define=_HAS_ITERATOR_DEBUGGING=0 toolset=msvc-11.0

However, when I include the library in my debug visual studio projects I still get errors like this:

(basic_iarchive.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in Game.obj

Which leads me to belive that my 'define' in the boost build did not have any effect. What is the proper syntax? I cannot find any examples, and the documentation dosnt say anything else on the matter.

EDIT: I would like to enforce that I want to define _HAS_ITERATOR_DEBUGGING=0 in my boost build

Answer 1

_ITERATOR_DEBUG_LEVEL is not boost's thing but part of standard library implementation that ships with MSVC. You must take greatest care to compile everything in your build with a consistent value of this setting. In many cases a violation it's diagnosed by the linker like the message you quote, unfortunately it can go undetected. As it changes the size and layout of most std collections and related stuff, guess what follows.

By default it is not set to anything, and when you include some standard header it looks for _DEBUG and sets itself to 2. Good way if nothing in the system ever sets it and you consistently use _DEBUG.

With boost I'm not familiar, but would guess the setting you quote would force the macro with value 0. If so, no wonder you have a discrepancy. Set it to 2, or if you mean 0, go ahead and use that in all your projects.

Answer 2

Adding define=_ITERATOR_DEBUG_LEVEL=0 works for me, as Igor commented.

_HAS_ITERATOR_DEBUGGING is then defined by the MS-headers based on the above setting, so you shouldn't try to set it directly.

Setting it to 0 improves debug performance dramatically in some cases (real-time 3d) so there are definitely use cases that speak for it, even though the pain of recompiling all DLLs that expose STL-containers/iterators in their interfaces.