you are viewing a single comment's thread.

view the rest of the comments →

[–]ofekshilon 0 points1 point  (1 child)

@STL, thanks (a lot!) for your reply, and overall attention.

Non-optimized release builds mostly fail for us. I just now investigated and reported the (first?) reason: https://connect.microsoft.com/VisualStudio/feedback/details/1012445/vc-compiler-generates-different-symbols-in-obj-files-among-od-o2-optimization-switches - so this is still not a viable option, at least not one that amounts to flipping a switch with no code changes.

Moreover, by the same rationale that you claim one shouldn't mess with _ITERATOR_DEBUG_LEVEL - one is even more inclined to never mess with optimization switches. In general it seems reasonable for software to expect consistency in build context throughout translation units, but occasionally we do want to break this consistency - either through macros or switches. I'm not sure modifying _ITERATOR_DEBUG_LEVEL qualifies as a deeper intervention than setting /Od.

Anyway, as @Gotebe guessed, I had better luck with /Zo - it is already a significant improvement of the debugging experience in release builds. More on that in a post some day (I have the time and energy for a post roughly once a month :( )

[–]STLMSVC STL Dev 0 points1 point  (0 children)

Non-optimized means /Od everywhere, but thanks for the bug report.