http://d.puremagic.com/issues/show_bug.cgi?id=7515
--- Comment #8 from bearophile_h...@eml.cc 2012-03-11 14:40:45 PDT --- (In reply to comment #7) Thank you for your answers. > If you want a truly generic mapping function which operates on ubyte and > creates an array which holds all of the possible values of that type, then it > makes no sense to be putting it in std.string. It should be more generic and > be > in std.array (though given that it wouldn't really make sense to do what > makeTrans and translate are doing with anything larger than a ubyte, I > question > how good an idea that would lbe). I have not asked for a truly generic function for std.array. So this problem doesn't happen. > If what you care about is strings, then there is no point in having an array > greater than 128 elements long, because there aren't any ASCII characters > greater than that. Having 256 is pointless and wasteful, because there won't > be > any characters that large. Not to mention, the _whole_ reason that you were > complaining about this in the first place was because the unicode-aware > version > of translate was slower than using maketrans/trnslate when dealing with pure > ASCII, and using 128 elements is going to be faster. Now I have had to use translate() for a different job: I have a good amount of 8-bit ASCII text in my language to process (http://en.wikipedia.org/wiki/Extended_ASCII ). It's not Unicode, and I don't think I can convert it to Unicode. I have to use translate() on this text. A 128-elements translate() isn't enough. The "waste" caused by using a 256 items array instead of a 128 items array is probably not significant. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
