Boost logo

Boost :

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.

(int)(std::pair<int, int>)(double)

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
> sequence:
> /**/

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:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at