Re: [boost] Re: new macro - BOOST_WORKAROUND(symbol, test)

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-08 12:34:48

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> On Fri, 06 Dec 2002 14:16:39 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>
>>
>>I've just checked in boost/detail/workaround.hpp, which defines the
>>BOOST_WORKAROUND macro.
>>
>>This macro can and should be used in place of explicit tests for
>>particular compiler/library/platform versions.
>
> Just some thoughts: I like the idea of such a macro, though the form
>
>    defined(symbol) && symbol test
>
> (or quasi-equivalent) is not the most general we may need for testing
> versions. But I don't like the current implementation, for a couple of
> reasons. Firstly, because it depends on a library header (cat.hpp).
> Call me pedantic, but though that file actually doesn't use
> workaround.hpp it could in the future, and even if that will never
> happen it is still an "exception" to the fact that libraries might
> depend on the workaround header, not vice versa. In fact, this would
> probably solved by:
>
> // untested
> #define BOOST_PSEUDO_IS_DEFINED(symbol) BOOST_JOIN(symbol, 1)
> #define BOOST_WORKAROUND(symbol, test) \
>          (BOOST_PSEUDO_IS_DEFINED(symbol) && symbol test)

This will fail if "symbol1" is defined, won't it?

> but, all in all, I would prefer a simple:
>
> #define BOOST_WORKAROUND(symbol, test) ((symbol != 0) && symbol test)
>
> Spartan as it may seem, it's only drawback is that, as you said, it
> doesn't detect an explicit define to zero. But it is extremely honest
> at showing that defect. The current implementation instead is much
> more cheating, in that
>
>  a) it "hides" its limitations about the range of possible values
>     (appending the digit 1 to a pp-number can of course result
>      in a too large number)
>
>  b) "hides" possible problems in the (unlikely, granted) case that
>      X is undefined but X1 is and you write:
>
>            BOOST_WORKAROUND(X, test)
>
>     (the result "unexpectedly" depends on the expansion of X1).
>
>
> I don't claim that you change the implementation, of course. Just that
> you consider these facts, at least eliminating the dependency from
> cat.hpp.

They're good arguments. I'm not averse to changing the implementation
to use your technique. If nobody objects to your idea while the dust
settles on other issues, I will do it.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution