Re: [boost] Re: [Config] Testing instructions for compiler vendors

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-12-14 15:01:33

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> BTW, IIF always bothered me when I saw it; it's non-memnonic, and I
> never knew what it did.  IF_BOOL would have been better in that
> respect.

It stands for "inline if" because it is doesn't do any checking.  The
condition *must* be 1 or 0 period.  BOOST_PP_IF is implemented in terms of
BOOST_PP_IIF, but using BOOST_PP_IF when the condition is guaranteed to be 0
or 1 is a waste of time.

> > ----- SPLIT -----
> >
> > #define SPLIT(n, im) CAT(ELEM_, n)(im)
> >
> > This one is trickier.  The argument 'im' is a single argument that
> > immediately expands to two arguments (in and of itself).
>
> OK.  What you mean is that im *must expand* to two arguments,
> though.  It's a requirement on the invoker of the split macro.

Yes.  It must be one argument that expands into two without intervention.
This is a common enough thing that needs to happen with various "detection"
types of macros.

> > So if we have the necessary extractors for something like this:
> >
> >     SPLIT(0, (!) <= 0x123) // yields:  !
> >     SPLIT(1, (!) <= 0x123) // yields:  <= 0x123
>
> Er,
>
>      SPLIT(0, OP (!) <= 0x123) // yields:  !
>      SPLIT(1, OP (!) <= 0x123) // yields:  <= 0x123

Yeah, sorry.  "OP (!) <= 0x123" yields "!, <= 0x1234" which is what we want
here.

> > Next we need two control path macros that represent the "normal" usage
and
> > the "extended" usage:
> >
> > #define NORMAL(symbol, test) && (symbol test)
> > #define EXTENDED(symbol, test) \
> >     && (BOOST_DETECT_OUTDATED_WORKAROUNDS != 0) \
> >     && 1 / ( \
> >                 BOOST_PP_SPLIT(0, OP test) (symbol BOOST_PP_SPLIT(1, OP
> > test)) \
> >                 ? 0 : 1 \
> >             ) \
> >             /**/
> >
> > And finally,
> >
> > #define BOOST_WORKAROUND(symbol, test) \
> >     ( \
> >         ((symbol != 0) IIF(IS_UNARY(test), EXTENDED, NORMAL)((symbol),
test)
> > \
> >     ) \
> >     /**/
>
> OK. I'd prefer to factor the initial && out of NORMAL/EXTENDED and
> into BOOST_WORKAROUND.  Any reason why not?

No, it is a relic of the way I first wrote it.

> > [Note:  The reason that I'm using "(!)" is that it warnings/errors when
the
> > expression:  "symbol op value" is _not_ true.  This, of course, is
> > equivalent to "(~)" but not "(?)".  The actual operator has to be used
> > somehow to enforce the proper syntax,
>
> Oh, I'm not so sure how valuable that is.  It seems as though people
> could screw this up by using (+) instead of (!).
>
> > "(?)" could be used this way because of the ternary conditional if
> > you want.]
>
> (!) is fine.

If you used (?) instead, it would absolutely force you to use (?) to
complete the ternary conditional.  The point of using it somehow, is to
enforce that it isn't this:   (aaaaaaaaaaaaaa) <= 0x1234 -- if I don't use
it, I can't tell the difference between '?', '!', and 'aaaaaa'.

> Someone expressed concern about using the PP lib in the definition of
> this macro, because, after all, the PP lib itself might want to use
> it.  I presume you're not worried about that, though.

The PP lib uses no other libraries.  It won't even use this one.  This is
primarily because the concerns are different in the PP-lib.  The bugs in
VC++ and Metrowerks are ones that break encapsulation.  The resulting fix is
to implement the workarounds over the entire library has a whole.  The
aren't specific enough to localize that cleanly.  I also consider the PP lib
to pontentially be *the* base-level library on a library dependency scale.
I like reuse, but only if it is "downward" reuse.  I.e. The preprocessor lib
doesn't use the MPL, but the MPL uses the preprocessor lib; the MPL doesn't
use library X, but library X uses the MPL.  I think this reuse ordering
models the phases of translation (including runtime).

Paul Mensonides