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 pp-lists?). 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".) Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/preprocessor-Sequences-vs-All-Other-Data-... Sent from the Boost - Dev mailing list archive at Nabble.com.