Re: [boost] Comment on string / unicode discussion

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-07-06 12:17:14

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>>
>>>
>>> How are these different from many of the iterators provided by
>>> http://www.boost.org/libs/iterator, particularly transform_iterator?
>>
>> http://www.boost.org/libs/serialization/doc/index.html describes
>> this.

Whoops - try http://www.boost.org/libs/serialization/doc/dataflow.html

>> All the "dataflow iterators" are derived from boost.iterator.  For
>> some I derived from transform iterator for others I derived
>> from filter and I forget the rest.
>
> I don't know what you mean by "derived" but if you're referring to
> regular C++ derivation, that generally doesn't result in a legal
> iterator class.  For example, the result type of operator++ is usually
> wrong.

That's what I'm referring to.  And it has required extra effort
to make operator++ work correctly.

>> Aside from implementing the transforming behavior required
>> for the specific instance, the only real addition is the
>> requirement that all of them have a templated constructor.
>
> Details would be helpful here.

See the above link.

>> This simple addition made all the difference for me.
>>
>> This permitted me to compose them to any ressonable
>> depth and sequence with just one (rather long)
>> typedef into a new iterator which can be used
>> just as easily as any other.

> The existing iterator adaptors are easily composed, so I'd like to
> know a little more about what you did, and gained.

I wanted to be able do things like the following:

a) define an iterator for transforming 8 bit octets into 6 bit octets
b) define an iterator which would render 6 bit octets into ascii
codes as used in base64 coding
c) define an iterator which would insert line breaks every 50 characters

I wanted to be able to develope and test each of these separately.

so far no real problem with the boost iterators.

Then I wanted to compose them with a typedef

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
);

Uh - oh - I can do the above - because I need to instanciate the iterator 
with
some sort of make_???_iterator.   This an extra pain and adds a lot of 
confusion
It also prevents me from doing something like:

std::copy(
    wchar_from_mb(base64_text(address))),
    wchar_from_mb((base64_text(
        address + count
    )),
    oi
);

should I find this convenient.

By adding the templated constructors and using them instead of 
make_???_functions
I was able to achieve what I desired.

>> I've never been able to convince anyone else
>> of the merit of the approach - but hope springs eternal.
>
> Maybe you never articulated sufficiently clearly what you added to the
> basics provided by the iterator library, and why.

LOL - apparently so.

Robert Ramey