[shared_ptr] [intel] Compile Errors with '#include <atomic>'
Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have). The problem is simple to repro: #include <atomic> #include <boost/shared_ptr> int main() { } The problem has been reported previously, but even in the latest version of the compiler (created and released well after the bug report) the problem seems to remain: http://software.intel.com/en-us/forums/showpost.php?p=160114 Here is a patch which I have used locally to successfully work around the problem, but I get the feeling that there is a better solution I'm overlooking... http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-shared_ptr-intel-fix-2... Has anyone else run into this problem who has come up with a better solution? Alternatively, if this is as good as it's going to get (maybe using a BOOST_WORKAROUND would be better so it can be disabled when/if the issue is fixed), would anybody be able to apply this to trunk? Thanks.
On Sat, Apr 21, 2012 at 4:55 AM, Joshua Boyce <raptorfactor@raptorfactor.com
wrote:
Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have).
The problem is simple to repro:
#include <atomic> #include <boost/shared_ptr> int main() { }
The problem has been reported previously, but even in the latest version of the compiler (created and released well after the bug report) the problem seems to remain: http://software.intel.com/en-us/forums/showpost.php?p=160114
Here is a patch which I have used locally to successfully work around the problem, but I get the feeling that there is a better solution I'm overlooking...
http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-shared_ptr-intel-fix-2...
Has anyone else run into this problem who has come up with a better solution? Alternatively, if this is as good as it's going to get (maybe using a BOOST_WORKAROUND would be better so it can be disabled when/if the issue is fixed), would anybody be able to apply this to trunk?
Thanks.
Ugh, it seems that Boost.Thread is also affected by this. Patch for future.hpp (disgusting like the last one, will probably need to be rewritten/cleaned up): http://dl.dropbox.com/u/74751/cpp/boost/patches/boost-future-intel-fix-20120... At last, my project finally builds with Intel C++.
participants (1)
-
Joshua Boyce