Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-12-08 11:54:10


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)

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.

Genny.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk