Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 06 Dec 2002 14:16:39 -0500, David Abrahams
> <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
