Major performance problem with std.array.front()
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Sun Mar 9 05:28:37 PDT 2014
On 09/03/14 04:26, Andrei Alexandrescu wrote:
>>> 2. Add byChar that returns a random-access range iterating a string by
>>> character. Add byWchar that does on-the-fly transcoding to UTF16. Add
>>> byDchar that accepts any range of char and does decoding. And such
>>> stuff. Then whenever one wants to go through a string by code point
>>> can just use str.byChar.
>>
>> This is confusing. Did you mean to say that byChar iterates a string by
>> code unit (not character / code point)?
>
> Unit. s.byChar.front is a (possibly ref, possibly qualified) char.
So IIUC iterating over s.byChar would not encounter the decoding-related speed
hits that Walter is concerned about?
In which case it seems to me a better solution -- "safe" strings by default,
unsafe speed-focused solution available if you want it. ("Safe" here in the
more general sense of "Doesn't generate unexpected errors" rather than memory
safety.)
More information about the Digitalmars-d
mailing list