On Tue, 12 Oct 2010 14:31:57 +0900, Daniel Murphy <[email protected]>
wrote:
While this is range based, I had something different in mind.
(Not these function names, just the basic idea of the signatures)
struct Base64Encoder(Range) if (isInputRange!Range &&
is(ElementType!Range
== ubyte))
{
// range methods
@property char front() { ... }
void popFront() { ... }
@property size_t length() { ... }
...
};
Base64Encoder!(Range) Base64Encode(Range)(Range r) if
(isInputRange!Range &&
is(ElementType!Range == ubyte))
{
return Base64Encoder!Range(r);
}
This way encoding would convert an input range of ubyte to an input
range of
char, and decoding would convert Range!char to Range!ubyte.
This way you would be able to use it with std.algorithm, std.range etc.
When called with an array the range would be able to provide length and
be bidirectional.
This way there would be no allocations inside the range at all.
Yes, your range doesn't need allocation.
However, users eventually need to store the result returned from the range
to the buffer allocated by themselves.
How to use the encoded / decoded result?
You could create and fill a buffer using
auto buffer = array(encode(data));
or fill an existing buffer using
copy(encode(data), buffer);
"copy(encode(data), buffer)" seems to be equivalent to 'encode(data,
buffer)'.
Sorry, I don't almost see the merit of your proposal.
Base64 is simple(ubyte[] -encode-> char[], char[] -decode-> ubyte[]).
Your range seems to be over-generalization to Base64...
P.S.
encode(InputRange, OutputRange) becomes a new function candidate for no
allocation.
Of course, decode too. These are inspired by your range.
Masahiro
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
