List of Phobos functions that allocate memory?

[Jonathan M Davis]

On Saturday, February 08, 2014 09:20:15 Andrej Mitrovic wrote:
> On 2/7/14, Jonathan M Davis <jmdavisProg at gmx.com> 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/mailman.66.1391838333.21734.digitalmars-d@puremagic.com

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