[Issue 4483] foreach over string or wstring, where element type not specified, does not support unicode
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Sun Jan 26 01:17:41 PST 2014
https://d.puremagic.com/issues/show_bug.cgi?id=4483
Walter Bright <bugzilla at digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|Other |All
--- Comment #11 from Walter Bright <bugzilla at digitalmars.com> 2014-01-26 01:17:28 PST ---
> You fail to recognize that it's broken from the begging.
I understand and recognize your arguments, I just do not agree with the
conclusion.
1. Silently breaking code with such a change is a seriously bad idea at this
point.
2. I do not agree with the hypothesis that the slowdown is trivial. I just got
done doing a project for a client, where high speed was essential. I got bit by
front() doing a decode. The speed hit was not acceptable, and I had to insert
lots of ugly casts to ubyte arrays. The code almost never needed a decode
character, but simply doing a copy() did a decode and then an encode. Arghh!
Actually needing a dchar is rather rare. The bulk of algorithms with strings
work better and faster using octets (like good ole' copy()). I've suspected for
a while now that std.algorithm is slower than necessary because the pointless
decoding going on, and I know that std.regex suffered serious slowdowns because
of it.
To me this is much like the recurring argument that D should hide the reality
of twos-complement arithmetic with various checks for overflows and carries. D
strings are octets, not dchars, and one simply needs to be aware of that when
programming with them.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list