Major performance problem with std.array.front()
Dmitry Olshansky
dmitry.olsh at gmail.com
Fri Mar 7 11:28:09 PST 2014
07-Mar-2014 23:11, Andrei Alexandrescu пишет:
> On 3/7/14, 9:24 AM, Vladimir Panteleev wrote:
>>> 5. Implement new std.array.front for strings that doesn't decode.
>>
>> Until then, how will people use strings with algorithms when they mean
>> to use them per-byte? A .raw property which casts to ubyte[]?
>
> There's no "until then".
>
> A current ".representation" property already exists that casts all
> string types appropriately.
There is however a big glaring failure: std.algorithm specialized for
char[], wchar[] but not for any RandomAccessRange!char or
RandomAccessRange!wchar.
So if I for instance get a custom slice type (e.g. a ring buffer), then
I'm out of luck w/o both "auto-magic dchar range" and special code in
std.algo that works with chars as code units.
If there is a way to exploit the duality of RA range of code units being
"is a" BD range of code points we certainly have failed with making it
work (first of all doing horrible job at generic-ness as mentioned).
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list