On Thu, Oct 14, 2010 at 10:45 AM, Andrei Alexandrescu <[email protected]>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.
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
