Tobias Schwinger <tschwinger@neoscientists.org> 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