[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