Subject: Re: [boost] Interest in Base2/16/32/64 Encoding Library?
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-07-08 01:31:00
Daniel Larimer wrote:
> On Jul 6, 2012, at 4:13 PM, Thomas Kemmer wrote:
>> There have been several suggestions for a Base64 encoding library on
>> this mailing list in the past. Most of them have been dismissed,
>> Boost already provides a Base64 implementation with
>> Boost.Serialization's "Dataflow Iterators". Though I appreciate the
>> dataflow iterator's design, from personal experience I think that for
>> the basic task of encoding/decoding, a higher-level interface, e.g.
>> one that takes padding and intermittent whitespace (MIME) into
>> account, would benefit many developers.
The "Dataflow Iterators" as I concieved for the serialization library
is effectively implemented in boost.range. boost.range wasn't
available when I made the serialization library.
No doubt that a higher-level interface would be attractive to
lot's of people and hence would be a good thing.
The real appeal of "Dataflow Iterators" / Boost.Range is as
an implementation technique. It shows how simple iterators
can be easily composed into more complex ones. So the
usage for base64 as well as other uses demonstrate
examples of the technique. I believe this is a very effective
and "boost like" way of going about things and would
be disappointed not to see it used in your higher level
interface/library. This techique permits doing something
like create an iterator which renders base64 in kanji
by composing the dataflow base64 iterator + a roman/kanji
iterator adaptor without writing more than a trivial bit
of new code. As I said, I would be sorry to see the
iterator adaptor composition technique not used.
Having said that, I do recognise that the "iterator adaptor
composition" in this case has some problems". The main
one is that it's hard to resolve the issue where by characters
are added as padding.
I just checked the code and it's clear you've put a lot
of effort into this. So good luck with this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk