Re: [boost] Is Boost interested in the Boost-based Base64 library

Subject: Re: [boost] Is Boost interested in the Boost-based Base64 library
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-06-10 20:51:27

On 10/06/2011 18:35, Robert Ramey wrote:
> Mathias Gaunard wrote:
>> On 10/06/2011 01:14, Robert Ramey wrote:
>>
>>> I think you'd find it interesting to see how the serialization
>>> library does it.
>>>
>>> ../boost/archive/iterators/base64_from_binary
>>> ../boost/archive/iterators/binary_from_base64
>>
>> The code of these is much more complicated than it needs to be; there
>> is  too much coupling between the algorithm and the iterator adaptor.
>
> well, it's implemented in terms of iterator adaptor.  I see that as a
> feature.
> This gives maximal efficiency and total compile time flexibility and
> leverages on working/tested/reviewed code - which to me is
> what boost is about.

Yes, it's a feature, but unfortunately the base64 logic is intertwined 
with the iterator logic, and concerns are not as well separated as they 
could be.

 From a glimpse at the code, I am also not really convinced that it's 
got maximal efficiency either, it could probably be faster by computing 
at compile-time the optimal bit twiddling logic and reducing the 
redundant branches.

> I can't see how another implementation which doesn't use
> the already made stuff can be faster or more efficient or
> add less code to the code base.

I have an implementation of a generic system that can generate, from a 
model of a very simple and explicit Converter concept, an iterator 
adaptor, an eager algorithm, a codecvt facet or a boost.iostreams filter.

The idea is basically that I put inside a concept the notion of a 
conversion step, and then I built an iterator adaptor that can work for 
any model of that concept.

A possible implementation of a base64 encoder Converter, along with a 
codecvt demo (hardly the best backend) is available at
<http://svn.boost.org/svn/boost/sandbox/SOC/2009/unicode/libs/unicode/example/base64.cpp>

It's not generic (in the sense that it doesn't allow N to M bit 
conversion like transform_width, it just does base64 -- after all it's 
only meant to be an example) but that's something that would also be 
fairly easy to do.

Now I am not suggesting that Boost should definitely use this, I'm just 
presenting alternatives.