Re: [boost] Comment on string / unicode discussion

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-07-06 13:50:40

Daniel Mitchell wrote:
> On Thursday 06 July 2006 11:17, Robert Ramey wrote:
>> typedef
>>     boost::archive::iterators::insert_linebreaks<
>>         boost::archive::iterators::base64_from_binary<
>>             boost::archive::iterators::transform_width<
>>                 const char *,
>>                 6,
>>                 8
>>
>>
>>         ,72
>>         ,const char // cwpro8 needs this
>>
>> base64_text;
>>
>> Wow - just great.  Now just construct an instance of base64_text -
>> and we're in business.  So I can do:
>>
>> char * address; // pointer to character buffer
>> ...
>> boost::archive::iterators::ostream_iterator<char> oi(os);
>> std::copy(
>>     base64_text(address),
>>     base64_text(
>>         address + count
>>     ),
>>     oi
>> );
>
> 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.

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.

What I would like to see is a code_cvt facet which used an iterator as 
template argument.  Combined with the above I could easily generate any 
code_cvt facet from my "stable" of composible iterators.  This could be 
attached to any output stream to do stuff like base64 output or utf8 output 
or whatever.

Note that the serialization library uses this to implment things like 
mb_from_wchar etc. so I would expect it would be easy to make things like 
utf8_from_mb.   and add this to the "stable" of dataflow iterators.

Robert Ramey