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

Subject: Re: [boost] [predef] Status and review results?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2013-05-03 00:40:18

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?

> 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.

> 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.

I'll make a note to document this rational in the documentation though :-)

-- 
-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo