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