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

Subject: Re: [boost] [predef] Status and review results?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-03 16:17:36

On Friday 03 May 2013 16:04:39 Jason Roehm wrote:
> 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.

+1

May I add that Boost.Config defines BOOST_GCC and BOOST_MSVC only for genuine 
GCC and MSVC and not for their pretenders. You would typically use these 
macros when you work around specific compiler bugs and __GNUC__ and _MSC_VER 
when you target code for GNU or Microsoft extensions. I think Boost.Predef 
should follow this practice, and its BOOST_COMP_* macros should unambiguously 
identify the compiler. Another set of macros can be made available to detect 
GNU or MS C++ dialect.