Re: [boost] Comment on string / unicode discussion

6 Jul 2006

      David Abrahams wrote:
...
"Robert Ramey" <ramey@rrsd.com> writes:
...
David Abrahams wrote:
...
"Robert Ramey" <ramey@rrsd.com> 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