From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-14 06:17:12
From: "Paul Mensonides" <pmenso57_at_[hidden]>
> I have been corresponding with Vesa about some of this stuff already (not
> docs, but the implementation),
> and I think that it is hard to finalize at this
> point. For instance, Vesa's implementation of BOOST_PP_WHILE represents
> 256 iterations. If he was to apply automatic recursion to that entire
> macros, then every one of those *_D macros (i.e. ADD_D, MUL_D, etc.)
> gotten rid of entirely because they would be unnecessary. The problem
> that would be massively inefficient to perform that kind of check
> 256 macros.
I'll have to trust you on that. FWIW, reports from the field indicate some
anecdotal compilation slowdown from recent changes.
> There are several alternatives that I'm looking into (and Vesa is
> also), such as only 'allocating' batches of iterations (i.e. only check
> or 10) or using a binary search (or a weighted binary search, or both) to
> improve the efficiency of such a strategy.
> As far as the documentation goes, it really needs a full-fledge
> preprocessor meta-programming. I.e. what kinds of idioms and techniques
> available, how to avoid certain traps, etc.. It also needs tutorials
> about each separate subset of the library (i.e. working with tuples,
> with cons-lists, working with loops, working with arithmetic, etc.), and
> the documentation needs step-by-step examples (not just completed
Agreed on all counts. It sounds like you have the right idea.
> My main problem is that I don't thoroughly know the Boost.Preprocessor
> I am getting to know it better as time goes by, but I have never actually
> it at all--just looked at, comprehended the implementation, and compared
> my own implementation of the same type of thing. Sometimes I like how it
> things better, sometimes not. Also, I don't know if I have enough
> with preprocessor meta-programming to make a relatively comprehensive
> introduction to the techniques involved. Though I may be more equipped
> than many--and possibly more importantly, I have some interest in it.
Yes. In fact, the hardest part of doing this well is understanding what
needs to be covered and how it must be structured. Once you make the
outline, filling in details is often easy enough for an experienced library
user to do it.
> Of course, this whole preprocessor thing was a huge side-trip from what I
> working on before (template meta-programming), which in turn was a huge
> side-trip from what I was working on before that.
Life is a series of those, I think ;-)
> However, I have been talking with Vesa, and things are improving (at this
> the implementation). Also, Vesa has told me that he plans to renovate
> documentation (except the reference part). The hard part is coming up
> worthwhile examples that aren't really complicated--and that is why
> on feature sets are necessary.
We could reduce some of the real-world examples needed by the Boost.Python
library, if that's any help.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk