Re: [boost] Recent PP changes

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-18 13:23:33

> from your boost root:
>
>     cvs update -rmpl-development boost/mpl
>
> > So, if you want to tell me what I need to do
> > or where to go for instructions, go ahead.

I tried the above like this:
cvs -z3 -d:pserver:anonymous_at_[hidden]:/cvsroot/boost update
boost/mpl

But this didn't work.  So I tried this:
cvs -z3 -d:pserver:anonymous_at_[hidden]:/cvsroot/boost
checkout -rmpl-development boost

That deleted everything, but got the mpl files.  So then I just co'd boost
(without mpl-development) and got all the other files back.

Obviously, I'm doing something wrong, so I'm going to the bookstore to get "Open
Source Development with CVS" by Moeshe Bar which was recommended in the
sourceforge documentation.

> See, this is just getting complicated. Since you understand what needs
> doing, I'd rather just give you CVS access so you can make and test the
> fixes yourself. Every time I bring the PP sources up-to-date and try some
> new patch that doesn't work, I end up having to recompile everything for
> all of the compilers I'm testing my code with. Why don't you send me your
> SourceForge username (get one if you don't have one).
>
> -Dave

I don't really know why VC++ is failing in certain cases without the delay
macros.  The best guess that I can make is that it is getting confused under
certain conditions and seems to be do a depth-first expansion--which is
incorrect.  In any case, after I made the modifications to if.h and bool.h, I
could preprocess the files that had errors in them (apply.h and
count_if.not.hpp) just fine with VC++ or Comeau C++.  The patches so far were
necessary parts of the fix, but I couldn't isolate where the problem was
occurring without looking at the source that caused the problem.  This is
definitely the fault of VC++.  It is doing macro expansion in an extraordinarily
hokey fashion.

My username at sourceforge is pmenso57.

Lastly, before all the delays are re-inserted, I'm wondering whether or not an
alternate implementation should be provided for compliant preprocessors.  I.e.

#ifdef BOOST_PP_DETAIL_EXTRA_DELAYS
    #define BOOST_PP_CAT(a, b) BOOST_PP_CAT_DELAY_X(a, b)
    #define BOOST_PP_CAT_DELAY_X(a, b) BOOST_PP_CAT_DELAY(a, b)
#else
    #define BOOST_PP_CAT(a, b) BOOST_PP_CAT_DELAY(a, b)
#endif
#define CONCAT_DELAY(a, b) a ## b

...because the extra delays reduce efficiency.  I don't know what Vesa wants to
do however.

Paul Mensonides