List of Phobos functions that allocate memory?

Marco Leise Marco.Leise at gmx.de
Fri Feb 7 20:29:35 PST 2014


Am Fri, 07 Feb 2014 22:42:00 -0500
schrieb "Jonathan M Davis" <jmdavisProg at gmx.com>:

> On Saturday, February 08, 2014 02:41:54 bearophile wrote:
> > Jonathan M Davis:
> > > The problem is that you need to check it. This is _slower_ than
> > > exceptions in the normal case,
> > 
> > Right, but verifying the correctness of the Unicode encoding of a
> > string probably on average requires much more than time than
> > testing a single conditional. So I think this tiny added time is
> > acceptable.
> 
> But why even do it in the first place then? The code is cleaner and less 
> error-prone if it uses exceptions. The only argument I can see being made for 
> not using exceptions with decode is efficiency, because it's more cumbersome 
> to use if it's returning error values of some kind rather than just throwing 
> in the rare case that there's a Unicode decoding error. It's also more error-
> prone than using exceptions, because most code will just skip checking the 
> result. That's one of the big reasons that error codes are generally a bad 
> idea.
> 
> But since decode has to do the same validity checks whether it returns an 
> invalid dchar or a Nullable!dchar or if it throws, I don't see why not having 
> the exception buys us anything. It just makes the API worse.
> 
> - Jonathan M Davis

I agree with both of you. The Unicode standard tells us that
it is correct to replace invalid data with that special code
point, so it should be used where applicable, e.g. when one
sanitizes an invalid string.
On the other hand exceptions are clearly superior to error
returns.

I guess we just have two use cases here. One where invalid
encoding is not an error (e.g. for sanitizing purposes) and
one where you don't want to lose information and have to
enforce correct encoding.
Name the first one "decodeSubst" maybe and have decode call
that and check for 0xFFFD?

-- 
Marco



More information about the Digitalmars-d mailing list