Re: [boost] Defining compilers suggestion

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-11 14:02:24

Tobias Schwinger <tschwinger_at_[hidden]> writes:

> David Abrahams wrote:
>> So, can you spell out what that means?  When I define
>> BOOST_DETECT_OUTDATED_WORKAROUNDS, what would the behavior be?
>> 
>
> Warn if the same compiler is in use

Same as what?

>  and BOOST_TESTED does not match.

Match what?  What could possibly match BOOST_TESTED?

> On second thought the proposed interface is still too complicated and not exactly 
> perfect yet. However, I'll try to explain why I think that something in this 
> direction could be quite useful:
>
> The current BOOST_TESTED_AT assumes that a higher version number of a compiler 
> implies a later release date or integration with Boost. 

No, it assumes a higher version number implies a more advanced version
of the compiler frontend.

> Looking at e.g.  VisualC-embedded or Borland BuilderX/Kylix it isn't
> necessarily the case.

I don't think that matters.

> Further, patch submitters often have more than one version of a particular 
> compiler around so we could allow to express that a workaround has e.g. been 
> tested with version two and three and version three does not require the workaround.

THe way you do that is:

    BOOST_WORKAROUND(SOME_PP_SYMBOL, < 3)

> If BOOST_DETECT_UNTESTED_WORKAROUNDS is defined we would get a warning for 
> compiler versions that have not been explicitly marked as tested.

Do you know how to portably generate a warning with the preprocessor?

> So if Boost is ported to a new version of a compiler we'll see all
> the workarounds in question, regardless whether the version number
> is the highest around.  For regression testing (and the officially
> supported compilers respectively) we'ld always want to define that
> macro so insufficient testing of a fresh patch shows up in the
> regression summary.

What problem are we currently having that would be solved by this
suggestion, even if you could implement it (which I don't believe is
possible, at least not the way you've got it currently formulated)?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com