[phobos] std.base64 replacement

[Daniel Murphy]

On Thu, Oct 14, 2010 at 10:45 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:
>
>
> 3. Same discussion about decode. This is actually more important because
> you might want to decode streams of dchar. This is how many streams will
> come through, even though they are technically Ascii.
>
> Accepting string and wstring causes problems as they don't define length,
and of course may contain non-ascii characters.  Is the phobos-standard way
to assume they contain only ascii characters and take the array length as
the string length?  (with checks in non-release mode)


@property ubyte[] front();
>


Regarding Daniel's approach with char/byte level ranges through and through,
> in an ideal world I'd agree. But I fear that the implementation would not be
> as efficient. (I suggest you benchmark it against Masahiro's.) Also,
> practically, more often than not I'll want to work one chunk at a time, not
> one byte/char at a time.
>

I could be wrong, but I don't think I've seen any ranges in phobos that
return more than one logical unit from front.  I understand this is common
with streams, but I'm unsure what the phobos policy is on doing this with
ranges.

A set of ranges that convert char[4] <=> ubyte[3] could be an option, but
the output would need to be flattened in order to use it with many
algorithms.  You may want to convert by chunks, but you usually want to work
with a range of ubyte/char, not a range of ubyte[]/char[].

I will do some benchmarks to see how much worse the range-based solution
performs.  I assume doesn't compare very well for the buffer -> buffer case,
but still fares better some applications. (eg. searching and other things
that don't need to convert the entire range).

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101014/2b44f21a/attachment.html>