Recall an earlier discussion of storing N ranges in a collection.  Boost.Assign looks good, but is inefficient.  I’m thinking of doing the same thing using some compile-time metaprogramming.  I think Fusion offers the tools I need, to have part metaprogram and part runtime.

 

Suppose my syntax is is:

 

          vector<whatever> vec= cat(R1)(R2)(begin1,end1)(R4);

 

for any number of parameters where each application of operator() can contain a Range-concept-supporting object or two parameters that are a pair of iterators.

 

The function call cat(R1) kicks it off, and each subsequent operator() adds to the Fusion sequence of ranges.  I’m fighting back confusion as to the meta/regular boundary, so any help is appreciated at this point.  So, the meta-ness is that the result of the chain is a single object without the runtime baggage needed to handle the heterogeneous nature -- that’s the advantage, right?

 

But then the run-time side needs to actually accumulate the values, which should be streamlined via the optimizer.  I need not just a list of types (MPL), but types holding values or references to values.  So operator() “does” a run-time push_back and the return type is a metaprogram.  I’m not sure what I’m doing yet, but that’s what I’m trying to get.

 

Finally, the conversion operator can see the whole thing and accumulate the sizes of the component ranges, pre-allocate the vector, and then iterate the Fusion sequence to process each range in the normal way.

 

One sticking point in my mind is how to handle Ranges that are whole STL collections.  In that case, I want to hold them by reference.  But other kinds of ranges... will references work with Fusion collections?  Will doing everything by reference optimize out OK, or do I need to use values to acheive that?  Does Range have some metaprogramming property for “best way to pass this kind of range”?

 

More advanced, down the road:  For now, I can assume that all ranges are random-access and can handle the size generic function.  Slightly better is to separate the code paths so random-access ranges are sized and other ranges are not, giving 0; then the pre-allocation will still help some, or be business as usual with no pre-allocation.  But more advanced would be to pre-allocate the total size (of the remaining portion of the list) as far as it is known, after concatenating a range that didn’t have an efficient size function.  So, given a mixed list, it will reduce the amount of re-copying that is done.  Not sure of the algorithm; point is, “do something” before or after a non-random-access range is processed.

So, I want to make sure I don’t paint myself into a corner, even if I don’t add this functionality initially.

 

Any suggestions (or code scraps!) are welcome.

 

Thanks,

--John

 

 

 

 

===== begin evil footer added by mailer gateway =====