私はこれが問題であることを確認しました - Microsoft の Stephan T Lavavej (STL!) がこれについてブログを書いています。
具体的には、次のように述べています。
一般的な問題は、リンカーがすべての One Definition Rule (ODR) 違反を診断しないことです。不可能ではありませんが、これは解決するのが難しい問題です。そのため、標準では、特定の ODR 違反を未診断のままにすることが明確に許可されています。
ビルド時にすべての ODR 違反をキャッチする特別なモードをコンパイラとリンカに持たせたいと思っていますが、それを達成するのは難しいことを認識しています (そして、おそらくもっと有効に利用できるリソースを消費します。より多くの適合)。いずれにせよ、ODR 違反は、コードを適切に構成することにより、極端な努力をしなくても回避できるため、私たちプログラマーはリンカー チェックの欠如に対処できます。
ただし、オンとオフを切り替えることによってコードの機能を変更するマクロは、ODR と危険なほどいちゃつきます。具体的な問題は、_SECURE_SCL と _HAS_ITERATOR_DEBUGGING の両方がまさにこれを行うことです。ビルド システムでプロジェクト全体でどのマクロを定義するかを既に制御している必要があるため、一見すると、これはそれほど悪くないように思えるかもしれません。ただし、個別にコンパイルされたライブラリは複雑になります。(たとえば) デフォルトである _SECURE_SCL をオンにして Boost をビルドした場合、プロジェクトで _SECURE_SCL をオフにしてはなりません。プロジェクトで _SECURE_SCL を無効にする場合は、それに応じて Boost を再構築する必要があります。また、問題の個別にコンパイルされたライブラリによっては、それが難しい場合があります (Boost を使用すると、私の理解によると、それを行うことができますが、方法がわかりませんでした)。
彼は後でコメントでいくつかの可能な回避策をリストしていますが、この状況に適切なものはありませんでした. 他の誰かが、 boost/config/compiler/visualc.hppにいくつかの定義を挿入することで、boost をコンパイルするときにこれらのフラグをオフにできると報告しましたが、これは私にとってはうまくいきませんでした。ただし、次の行VERBATIMをtools/build/v2/user-config.jamに挿入するとうまくいきました。ジャムを促進するには空白が重要であることに注意してください。
msvc を使用: 9.0 : : <cxxflags>-D _SECURE_SCL=0 <cxxflags>-D _HAS_ITERATOR_DEBUGGING=0 ;