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