Re: [boost] [predef] Status and review results?

On 05/02/2013 11:40 PM, Rene Rivera wrote:

On Thu, May 2, 2013 at 1:37 PM, Ioannis Papadopoulos wrote:

...

While making the patches for I noticed the following (using test/info_as_cpp.cpp) :

For Intel 13:

** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_32 = 60000000 (6,0,0) | Intel x86-32 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_EDG = 40400000 (4,4,0) | EDG C++ Frontend BOOST_COMP_GNUC = 40700000 (4,7,0) | Gnu GCC C/C++ BOOST_COMP_INTEL = 30100000 (3,1,0) | Intel C/C++ BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_LANG_STDCPP = 271100001 (27,11,1) | Standard C++ BOOST_LIB_C_GNU = 21500000 (2,15,0) | GNU BOOST_LIB_STD_GNU = 420900021 (42,9,21) | GNU BOOST_OS_LINUX = 1 (0,0,1) | Linux BOOST_OS_UNIX = 1 (0,0,1) | Unix Environment

It detects three different architectures (but it does not say which one I am using).

Interesting.. On my x86 Mac with Xcode/GCC/LLVM it only detects x86_64..

=== ** Detected ** BOOST_ARCH_X86 = 1 (0,0,1) | Intel x86 BOOST_ARCH_X86_64 = 1 (0,0,1) | Intel x86-64 BOOST_COMP_GNUC = 40200001 (4,2,1) | Gnu GCC C/C++ BOOST_COMP_LLVM = 1 (0,0,1) | LLVM BOOST_ENDIAN_LITTLE_BYTE = 1 (0,0,1) | Byte-Swapped Little-Endian BOOST_LANG_OBJC = 1 (0,0,1) | Objective-C BOOST_LANG_STDC = 1 (0,0,1) | Standard C BOOST_OS_MACOS = 100000000 (10,0,0) | Mac OS ** Not Detected ** ===

And given the version number it detects for you on x86_32 of 6.0.0 it means that the Intel compiler is, I would guess, trying to say that it's targeting both at the same time? It would be nice decipher why it's doing that. Could you send me the default preprocessor macros it defines for you?

I'm attaching both for intel 12.1 and intel 13 (they're similar).

...

It also incorrectly says that it is GCC compiler. This is because Intel likes to do that for compatibility with GCC (I believe clang also defines __GNUC_).

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 make a note to document this rational in the documentation though :-)