On 05/03/2013 03:02 PM, Ioannis Papadopoulos wrote:
This is actually intentional, even if a bit confusing. If a compiler decides that it wants to emulate another compiler it's OK for me to detect both compilers at once. It's then up to users to decide if the compiler does actually emulate the compiler correctly. Basically I err on the side of more information.
That's fine, but then BOOST_COMP_GNUC then is not just "GNU C/C++ compiler", but rather "GNU C/C++ and all the ones that emulated it".
I think that defeats the purpose of detecting the compiler.
This leads to the question that if another macro is required that says that the compiler may identify itself as a GCC (or whatever else).
A user would need to decide if they care about a compiler claiming emulation of another compiler. For example by testing for the Intel compiler first.
However, isn't that boilerplate code for the user that could be handled in Boost.Predef? I believe that it would be more useful to get which compiler I'm using AND a macro that says that it offers GNU compatibility for example (I am not aware of another compiler that other compilers try to impersonate).
I'll throw in my small voice to agree with Ioannis. While the Intel compiler does emulate a lot of GNU extensions, most of the time, if I'm trying to detect the compiler that is being used, I'm very much concerned with the distinction between gcc and icc. Specifically, if you're trying to write conditional statements to work around a compiler bug, then it would be nice if Boost.Predef could be used to easily get an unambiguous answer about which compiler is actually in use. Maybe it would make sense to have two parallel interfaces: one that treats Intel/GNU as equivalent and another more pedantic one that does not. Jason