Re: [boost] Defining compilers suggestion

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-16 08:52:50

David Abrahams wrote:
> Andrey Melnikov <melnikov_at_[hidden]> writes:
> 
>>What about
>>
>>BOOST_WORKAROUND_BEFORE(GCC, 3,2,3)
>>BOOST_WORKAROUND_AFTER(GCC, 3,2,3)
>>BOOST_WORKAROUND_STARTING_FROM(GCC, 3,2,3)
>>
>>and other plain English words instead of syntactic tricks with putting < 
>>signs as macro parameters? Is it going to be more verbose and cryptic 
>>than using macrost with < ?
> 
> 
> Why do you call that a "syntactic trick?"  The operator gets used in
> the macro expansion and ends up being used by the preprocessor with
> the obvious semantics.  Just about every other token in 
> 
>   BOOST_WORKAROUND(GCC, >, 3,2,3)
> 
> is trickier than the ">".

I didn't mean a preprocessor trick. I only mean that for people it's 
unusual to see ">" sign alone or in an "unary" notation like "> 030203". 
  They will have to look at the macro itself to see how this ">" works.

> 
> The desire to spell out comparison operations as english words seems
> akin to the desire to embed compiler/ide versions in macro names.
> 
It really is akin. I'd like to see something more transparent and 
intuitive. I don't like the idea with words very much, but I don't like 
">" s

> 
>   #if !BOOST_WORKAROUND(MSVC, <=, 7,0,0) && !BOOST_WORKAROUND(MWERKS, <, 9,0,0)
> 
> 
>>Can we get rid of these "!" signs?
>>
>>!a && !b
>>
>>looks too verbose to me. 
> 
> 
> You can always write:
> 
>   #if !(BOOST_WORKAROUND(MSVC, <=, 7,0,0) || BOOST_WORKAROUND(MWERKS, <, 9,0,0))
> 
> but it's not much better.
> 

Do you think an empty branch and #else is worse than "!" ? Negations are 
rather hard to decipher.

#if BOOST_WORKAROUND(MSVC, <=, 7,0,0) || BOOST_WORKAROUND(MWERKS, <, 9,0,0)
// these compilers doesn't support these features
#else
// actual code for cases when no workarounds are nesessary
#endif

I always decode the former expression to the latter in my mind. I think 
#else is a better way to express a negation than "!" in this case.

Andrey