On Thursday 06 July 2006 12:50, Robert Ramey wrote:
Daniel Mitchell wrote:
So the advantage is the ability to construct a base64_text iterator directly from a char const* without manually constructing each of the underlying iterator adaptor layers. That's neat, but wouldn't a function
Yes - the newly created iterator - created with the typedef - hides all the underlying implementation just presents the "composed" interface.
base64_text make_base64_text_iterator( char const* );
work just as well?
How would I make such a function automatically? wouldn't have to do something like
base64_text make_base64_text_iterator( make_insert_linebreaks<...>( make_transform_width<...>(char const *) ) ) and not a LOT of stuff goes in to the ... But maybe it could be made to work. I just much preferred the idea of not having extra make_??? functions.
I was actually thinking of something a little less general and a little more direct like base64_text make_base64_text_iterator( char const* c ) { typedef transform_width<char const*,6,8> transform_iter; typedef base64_from_binary<transform_iter> base64_from_binary_iter; return base64_text( base64_from_binary_iter( transform_iter( c ) ) ); } However...
The method I used lets me make a "stable" of iterators and compose them at will. The generated iterators (derived from boost iterator adaptor) are all (I think) legal iterators and can be used in any STL algorithms. It comes close to implementing what people are a talking about now. And it does all te heavy lifting at compile time so that the the compiler can inline everything.
...I can see now that the above would be inadequate because you don't want to write a make_xxx_iterator function for each new combination of iterators. Sorry, I wasn't thinking "big picture." The method you suggest where each fundamental iterator (transform_width, base64_from_binary, and so on) gets its own make_xxx_iterator function and those functions are chained together to generate the right type is better anyway, and there's no question that the template constructors offer a much nicer syntax. D.