David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
Thanks; I think I see why you need the templated ctors now.
w.r.t. composing with a typedef, would
boost::archive::iterators::insert_linebreaks< boost::archive::iterators::base64_from_binary< boost::archive::iterators::transform_width< const char *, 6, 8 >::type >::type ,72 ,const char // cwpro8 needs this >::type base64_text;
be much worse, for your purposes?
Hmmm - I read this as creating an instance of base64_text - presumably on the stack.
Eh? All I did was make an exact copy of code you posted, and change ">" to ">::type" everywhere.
Oh - I only noticed that the word "typedef" was gone. Without looking at exactly what I did in detail and just commenting from a users's pespective - I don't see a big problem. Maybe its even better in that it is explicit about exactly what we're doing - composing iterator types to create a new iterator type. But then - if I want to use base_64_text somewhere - where does the ::type go? That is: where would base_64_text::type come from? Currently - every composed iterator can be used as a component in another iterator. In fact, in the serialization library I did this a couple times just to keep the code readible. If STL didn't use pairs of iterators everywhere, we might not even need the typedef - just make a composed construction - but that gets very tedious when one needs more than one of the same type. FWIW - my main interest really wasn't for converting strings of characters. I've been thinking for a very long time about what I would want in a "views" type library for relational algebra. Hence the name "Dataflow". I would really like to use this to generate at compile time a seqence of operations on data tuples. That is I would like to have select, join, project, cat, etc. I suppose this is probably very close to what fusion already does - but I havn't looked at it. Most database systems rely on very elaborate precompiled functions composed at runtime. I would hope that using something like the above along with a very good compiler would result in much faster programs for database operations. Heck I would even consider making a system which compiled each query on the fly. I've become convinced that with templated constructors and the iterators that are already in there (zip, filter, etc.) I'm probably very close to where I wanted to be originally. However, now I'm involved in other kinds of applications so I don't have the motivation to take things to what I see as their logical conclusion. Oh well. Robert Ramey