Opened 10 years ago
Closed 10 years ago
#6843 closed Patches (fixed)
[Intel C++] Compile Errors with '#include <atomic>'
Reported by: | Owned by: | viboes | |
---|---|---|---|
Milestone: | Boost 1.54.0 | Component: | thread |
Version: | Boost 1.49.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Under Intel C++ (12.1) on Windows, in C++0x mode, the following fails to compile:
#include <atomic> #include <boost/thread.hpp> int main() { }
The problem has been discovered previously:
http://software.intel.com/en-us/forums/showpost.php?p=160114
However there seems to be no forthcoming fix on Intel's part.
Attached is a patch to fix this problem. It will probably require a bit of extra wrapping though (to check for Intel version and C++0x mode).
Attachments (1)
Change History (8)
by , 10 years ago
Attachment: | boost-future-intel-fix-20120421-0519.patch added |
---|
comment:1 by , 10 years ago
Component: | thread → smart_ptr |
---|---|
Owner: | changed from | to
Hi,
I guess this problem is related to Boost.SmartPtr as the functions atomic_xxx are defined in smart_ptr/shared_ptr.hpp.
comment:2 by , 10 years ago
Right, but doesn't it need to be worked around at the call site (like I've done in my patch)? How would you propose to fix it in shared_ptr at the point where it's declared/defined? I'd love to hear if you have a better way to fix it.
Thanks for taking the time to read and respond to the ticket.
comment:3 by , 10 years ago
Component: | smart_ptr → thread |
---|---|
Owner: | changed from | to
Status: | new → assigned |
An alternative could be to use a file that does the undef of all the concerned macros and another that does the redef.
#include <boost/detail/atomic/undef_macros.hpp> if(!atomic_load(&future_)) { future_ptr blank; atomic_compare_exchange(&future_,&blank,future_ptr(new detail::future_object<R>)); } #include <boost/detail/atomic/redef_macros.hpp>
This has the advantage to have less noise. The same kind of patch can be applied to #6842
follow-up: 5 comment:4 by , 10 years ago
Yep, that would work great. Like I said originally, my first patch was a massive hack because I just wanted to get my development unblocked.
Your solution looks much nicer, and I look forward to not having to patch my copy locally in the future. :)
Thanks for looking into it again.
comment:5 by , 10 years ago
Replying to Joshua Boyce <raptorfactor@…>:
Yep, that would work great. Like I said originally, my first patch was a massive hack because I just wanted to get my development unblocked.
Your solution looks much nicer, and I look forward to not having to patch my copy locally in the future. :)
Thanks for looking into it again.
It will be too late for 1.54. I will try it very soon.
comment:6 by , 10 years ago
Milestone: | To Be Determined → Boost 1.54.0 |
---|
Committed revision [83903] including new files. Committed revision 83904 specific thread patch.
comment:7 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fist patch. Massive hack. Needs improvement.