Re: [boost] [binary-int] pre-release available

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2005-09-10 05:19:56

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Matt Calabrese

> After using AUTO_REC to deduce the recursion depth and pass 
> it to an _S form 
> of the BINARY_LITERAL macro, just as I am doing with the 
> BINARY_LITERAL and 
> BINARY_LITERAL_D macros with DEDUCE_D, I was getting errors 
> concerning the 
> concatenation onto BOOST_PP_SEQ_FOLD_LEFT_ for the S form 
> from TRANSFORM. 
> Again, though, this may be do to my own misunderstanding of the 
> preprocessor, but I believed it wasn't working because 
> TRANSFORM called 
> SEQ_FOLD_LEFT_S via a direct ## operation as opposed to using 
> CAT and was 
> concatenating the macro I was using before it was expanded. 
> Correct me if 
> this was an improper assumption and if there wasa fault in my 
> own doing. 

(Hmmm.  I wonder why I don't have a DEDUCE_S.  I'll fix that; it must have been
an oversight.)

The library typically directly concatenates those arguments.  I.e. it assumes
that they are already expanded before entry to the macro.  There are several
reasons for this, mostly related to encapsulation on broken preprocessors
(avoiding CAT uses).  In any case, what you need is a delay.  Instead of

#define A() SEQ_TRANSFORM_S(DEDUCE_S(), ...)

...use...

#define A() B(DEDUCE_S())
#define B(s) SEQ_TRANSFORM_S(s, ...)

This *should* work, but the possibility exists that it won't (on VC, see below).

> 1) Is there a reason why you're rolling your own COMPL 
> instead of using
> > BOOST_PP_COMPL? Did it fail to work correctly for some reason?
> 
> 
> Yes. If I replace that code with a call to BOOST_PP_COMPL, at 
> least in VC++ 
> 7.1 which is what I was testing it on, I was getting errors. 
> Try it out by 
> just replacing the code with a call to BOOST_PP_COMPL. If 
> there is something 
> I am doing wrong, please tell me.

It isn't you.  You've just run into one of the many ways in which VC's
preprocessor is broken.  It is probably better to leave your workaround in
place, because changing the library implementation is likely to break code.  VC
has a remarkable tendency to do everything out of order--picking up things at
later times that should have been done far earlier.  This makes that
preprocessor *extremely* difficult to work with for anything that relies on
expansion order.  The pp-lib does do this, of course, but it bends over backward
to support VC as well as it does (the pp-lib source is, IMO, more workaround
than concept).

> 2) The pp-lib already has an BOOST_PP_IS_NULLARY. However, it is not a
> [...]
> 
> Perhaps then I should change back to the less-elegant yet 
> possibly more 
> portable way I was doing it which did not use IS_NULLARY or IS_UNARY 
> concepts -- from the 2nd out of the 3 files I posted 
> (binary_literal.hpp), 
> unless you have a better solution?

That might be a good idea.  IS_NULLARY and similar ilk are not as stable across
preprocessors as other library primitives.  They are perfectly stable on
non-fundamentally-broken preprocessors, of course.  However, even with the
workarounds, they aren't totally stable on VC and MW < 9.  (It is difficult to
get anything that relies on expansion order stable on these two preprocessors
particularly.)

Regards,
Paul Mensonides