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

Subject: Re: [boost] Is Boost interested in the Boost-based Base64 library
From: Fernando Pelliccioni (fpelliccioni_at_[hidden])
Date: 2011-10-13 08:07:38

On Thu, Oct 13, 2011 at 1:27 AM, Robert Ramey <ramey_at_[hidden]> wrote:

> Fernando Pelliccioni wrote:
> > On Wed, Oct 12, 2011 at 2:06 AM, Robert Ramey <ramey_at_[hidden]> wrote:
> >
> >> Fernando Pelliccioni wrote:
> >>> On Fri, Jun 10, 2011 at 9:51 PM, Mathias Gaunard <
> >>
> >>> I want to write a Converter for *base64_encoder* that works with
> >>> Boost.IOStreams.
> >>> Do you have a guide  ?
> >>
> >> Hmmm. ... that's exaclty what the base_64 code in the serialization
> >> library does.
> >>
> >> I would think that wouldn't be too hard to use for this porpose.
> >>
> >> If one had nothing else to do this code could be used to
> >> generated code_convert facets at compile time in a similar
> >> manner to the way it generates string conversion code
> >> at compile time.  I believe that final result would be pretty
> >> useful.  It would be useful for all standard i/o streams.
> >> I believe that it would be quite efficient - as I believe
> >> the current library is.  Making this as a library of
> >> code convert facets would be a stricky job -as
> >> any library which works with standard code and
> >> real compilers and libraries is.
> >>
> >>
> >
> > Hi Robert,
> >
> > I want to use it with IOStreams Filters.
> > I understood that Mathias has an implementation that works with it.
> >
> > Something that concerns me about base64 code in serialization is the
> > following error:
> >
> >     http://lists.boost.org/boost-users/2008/08/39798.php
> >
>
> I'm not sure it's an error. The nature of base64 is that it has to be a
> multiple
> of 3 bytes.  You have to pad it on output.  The serialization
> library does this as it has to. I don't remember if it does it as part
> of the base64 conversion or outside of it.
>
>
Is there an iterator adapter for padding ?
base64_from_binary does not pad the bytes.

Regards,
Fernando.