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, since 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. Robert Ramey