|
Boost : |
Subject: Re: [boost] Is Boost interested in the Boost-based Base64 library
From: Fernando Pelliccioni (fpelliccioni_at_[hidden])
Date: 2011-10-11 15:50:09
On Fri, Jun 10, 2011 at 9:51 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> wrote:
>
> 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<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.
>
>
Hi Mathias,
I want to write a Converter for *base64_encoder* that works with
Boost.IOStreams.
Do you have a guide ?
Thanks and regards,
Fernando.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk