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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-16 08:33:31

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

> ----- 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.

I understand what you're saying, but I think "inline if" doesn't
reflect what it's doing and IIF is still not memnonic.

>> > [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'.

Yes, but that would force inversion of the conditional, which would
look weird.

>> 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).

I have no problem with it, but I'd like to hear at least one more
opinion (other than Gennaro's) before we move forward with it.  This
macro will be used in every Boost library, so if people find it
terribly odious it will be a failure.

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