[phobos] std.base64 replacement
Sean Kelly
sean at invisibleduck.org
Thu Oct 14 08:06:36 PDT 2010
The decode length doesn't have to be exact. Just make it a reasonably close upper bound. That's generally only used for preallocating a destination buffer anyway.
On Oct 14, 2010, at 1:21 AM, Daniel Murphy wrote:
> On Thu, Oct 14, 2010 at 4:59 AM, Masahiro Nakagawa <repeatedly at gmail.com> wrote:
> I wait no-caching implementation. I think Range should not have useless state.
> In addition, current implementation seems to be still more complex than necessary.
>
>
>
> I thought you might say that.
> http://yebblies.com/rangebase64nocache.d
> These ranges only read the bits that they actually need off the input, only converting one output item per popFront. I don't consider this a better solution. I haven't adapted length to work with this version, but I will if this implementation is actually going to be used.
>
> I'd welcome any ideas/suggestions on how to simplify the implementation of either version, especially the Decoder length, which is considerably ugly.
>
>
> I don't think so. Range is a good concept, but not all.
> I think usability is a most important factor for module API.
>
>
>
> Base64's API is following:
>
> encodeLength(length);
> encode(src, dst);
> encode(src);
> encoder(returns Encoder!(char[]) or Encoder!(char))
> decodeLength(length);
> decode(src, dst);
> decode(src);
> decoder(returns Decoder!(ubyte[]) or Decoder!(ubyte))
>
> Do you see any problems?
>
> Looks fine to me.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
More information about the phobos
mailing list