On Saturday, February 08, 2014 09:20:15 Andrej Mitrovic wrote: > On 2/7/14, Jonathan M Davis <[email protected]> wrote: > > However, I would argue that assuming that everyone is going to validate > > their > > strings and that pretty much all string-related functions shouldn't ever > > have > > to worry about invalid Unicode is just begging for subtle bugs all over > > the > > > > place IMHO. > > I suggested we would introduce an overload, not replace the existing > function, so this isn't an issue. > > > The problem is that you need to check it. This is _slower_ than exceptions > > in > the normal case, as invalid Unicode should be the rare case. > > Do you have any benchmarks for this? I have vague memory about > complaining that the exception code is *de-facto* slower, regardless > of input. But I'll try to provide some test-cases later and see where > we're at.
The exception version has to all of the same checks that the version which returns an error value would have to do, while the one returning an error value which had to be checked for validity would have an extra check. So, the only ways that the exception version would be slower are if the plumbing for being able to throw an exception from the function makes it slower (assuming that the other would be nothrow) or if the optimizer just does worse with the exception one for some reason. Because the number of operations that the actual D code would be doing in the successful case would be greater for the non-throwing version. Code generation can do entertaining things to efficiency though, so benchmarking would be required to see what would actually happen. However, as I stated in another post, I've reconsidered the situation. I think that I misunderstood what Dmitry was suggesting and that checking the error value is not actually necessary: http://forum.dlang.org/post/[email protected] And if that's the case, then we can probably move towards having decode not throw and possibly getting rid of UTFException altogether (certainly, most code wouldn't throw it or have to worry about it, since decode and stride are the two main cases where that's a concern, and if they don't throw anymore, then UTFException would have very little use). - Jonathan M Davis
