Re: [boost] Comment on string / unicode discussion

From: Daniel Mitchell (danmitchell_at_[hidden])
Date: 2006-07-06 14:56:40

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.