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 <[email protected]> > 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
