Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-04-23 10:01:41
Paul Mensonides wrote
> Hello all.
> In the past, I've said several times that sequences are a superior to
> every other data structure when dealing with a collection of elements
> (tuples are better in some very specific contexts).
Something that I found missing from Boost.PP docs is computational
complexity (in terms of number of required macro expansions?) of the
different algorithms for the different data structures. I take it that
sequences have the best performances (i.e., smallest pp time because
smallest number of macro expansions -- is that true?) but is that true for
_all_ sequence algorithms when compared with other data structures? or are
some tuple/array algorithms faster than the pp-seq equivalents?
For example, I would have found such an analysis of Boost.PP computational
complexity useful when programming complex pp macros (i.e., Boost.Contract).
I've ended up using pp-lists everywhere and that was probably a very bad
choice (and in fact Boost.Contract compilation times are huge :( ). I've
used pp-list just because they handle nil "for free" but I could have used a
pp-sequence (nil)(elem1)(elem2)... -- with a bit more implementation work to
deal with the leading (nil) -- had I saw evidence that the pp-sequence
implementation would have been truly faster.
One of those reasons is that, if a library is built for it, non-unary (or
even variadic) elements are natural because the structure of the sequence
itself encapsulates each element.
This would be very convenient. I programmed a case-by-case version of these
in Boost.Contract but not a general variadic extension of pp-sequence.
> Another reason is that, if a library is built for it and if placemarkers
> ala C99/C++11 are available, there is a natural representation of the nil
This would also be very convenient. But also automatically handling `(nil)`
for nil sequences would be very convenient (and still faster than
As for adding Chaos to Boost.PP, I asked "why not" before and the issues
with MVSC pp came about. Is this an opportunity to fix MSVC's pp? ;) (Some
bugs have already been reported but unfortunately resolved as "won't fix".)
-- View this message in context: http://boost.2283326.n4.nabble.com/preprocessor-Sequences-vs-All-Other-Data-Structures-tp4576239p4580498.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk