RE: [boost] Re: [preprocessor] BOOST_PP_IS_UNARY for Borland

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-08-16 12:53:44

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel James

> Paul Mensonides wrote:
> > I see no problem with adding the functionality, but the 
> macros still 
> > cannot safely be made public.  On other compilers (besides 
> Borland), 
> > their use causes stability problems.  Using something like 
> the above 
> > doesn't help (it would actually be slightly worse) because of the 
> > reliance on intermediates in the argument--which requires that 
> > expansion order proceed as it should (which is not the case 
> on some preprocessors).
> 
> That's a shame. I find it very useful.

I know.  They (and other types of detection macros) are very useful.  Right now,
the Borland configuration is used by the IBM preprocessor and the Sun
preprocessor also.  I'd like to know whether or not those macro definitions work
correctly on those preprocessors before I add it.  Though those macros aren't
part of the public interface, they are part of the internal interface.  I.e.
they are used internally as if they were a public interface (though they are
used carefully on some preprocessors).  They are stable, and the worst thing
that might happen in the future is that they will be moved to a different
directory.  Thus, you can use them, but beware of VC and versions of MWCW prior
to v9.  They in particular have severe problems with expansion order.  E.g. VC
will even fail this test:

#define IM 1, 2

#define A(im) B(im)
#define B(x, y) x + y

A(IM)

> >>Also, with a full working BOOST_PP_IS_UNARY, I think it should be 
> >>possible to make BOOST_PP_SEQ_NIL act as an empty sequence, 
> if I write 
> >>a patch to do that would it be accepted?
> > 
> > It is already possible because the identifier is known.
> 
> I should have realised that, since that's how lists work.

Exactly.

Note, BTW, that Borland's non-integrated command line preprocessor (i.e. not the
compiler itself in preprocess-only mode) is a pretty good preprocessor.  It
doesn't have the weird identifier-splicing bug that makes the straightforward
version of IS_UNARY (etc.) not work.  Last time I checked, it can even handle
Chaos.

> > Lack of a nil sequences
> > (until we get placemarkers) was a conscience decision.  An 
> important 
> > property of sequences is the ability to directly append.  By 
> > definition, if A and B are both sequences, then A B is also 
> a sequence.
> 
> That makes sense. I guess my version isn't that useful then.

It isn't that it isn't useful, because it is.  Lack of nil is an important
limitation of sequences.  However, having an alternate representation (such as
SEQ_NIL or even ~) leads to algorithmic code that constantly checks for nil when
building a sequence--either with a predicate (like IS_CONS or IS_NIL) or
indirectly though a CONS that is does that test.

> But, it's a nice trick and I can use it in my own stuff, 
> which will probably never work on preprocessors where 
> BOOST_PP_IS_UNARY is unstable.

Regarding the instability:  the macro itself is stable, but the input is not
which can foul up the internals.  The library itself does a ton of extra
scaffolding to force expansion order when it is important (for VC and MWCW < 9)
it does this globally across the entire library.  However, that scaffolding does
not exist in user code (nor should it have to if at all possible), and IS_UNARY
(etc.) cannot force an arbitrary amount of expansion to account for it.  You'd
be surprise how much stuff doesn't expand when it should on those preprocessors
that happens to get picked up later.  (You might have guessed that I really
really hate those preprocessors.)

Regards,
Paul Mensonides