On Fri, Jun 10, 2011 at 9:51 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> 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.