#5406 closed Bugs (wontfix)
Incorrection assumption of Intel C++ Composer for Windows behaviour for c++0x features
| Reported by: | Owned by: | John Maddock | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | config |
| Version: | Boost 1.46.1 | Severity: | Problem |
| Keywords: | Cc: |
Description
I have confirmed with Intel the behaviour of C++ Composer XE's behaviour with respect to how it manages C++0x features it supports which VS 2010 SP1 doesn't support. You can read about it here: http://software.intel.com/en-us/forums/showthread.php?t=81434&p=1#144607
In a nutshell, Intel partially supports strongly typed enums while Microsoft doesn't (at least not c++0x syntax). However in boost/config/compiler/intel.hpp, it assumes that Intel and MS supports the exact same c++0x language features.
I have just checked the trunk, and the line indicating support for scoped enums (L212) has been commented out. However, boost can compile correctly if /Qstd=c++0x is specified and that line is not commented. It might be a small thing, but it is good if this can be fixed.
Change History (2)
comment:1 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 11 years ago
I guess my main point for posting this ticket is that C++0x language support differs between VC++ and Intel C++, but the structure of the header file cannot support such differences.
A good example is nullptr support. If boost starts using nullptr, VC++ supports that keyword but not Intel C++.
That's why my ticket title is not about scoped enum but about the assumption made in the logic of deciding what C++0x features the compiler supports.
I belive it's deliberately disabled, Intel's support for scoped enums is officially described as "partial": http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler/
And I believe it did actually break stuff when that line was briefly enabled, so for now it stays disabled. Sorry!