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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk