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

Subject: Re: [boost] [predef] Status and review results?
From: Ioannis Papadopoulos (ipapadop_at_[hidden])
Date: 2013-05-03 15:02:50

On 05/02/2013 11:40 PM, Rene Rivera wrote:
> On Thu, May 2, 2013 at 1:37 PM, Ioannis Papadopoulos
> <ipapadop_at_[hidden]>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 :-)
>
>