Checking string allocations (was Re: String literals, ASCII vs UTF-8)

[Michael Meeks]

On Fri, 2012-03-02 at 17:16 +0000, Caolán McNamara wrote:
> Yeah, back the O[UString contents with direct new/delete calls in a real
> implementation body instead of current thin header-only wrapper around
> the C-API which backs onto rtl_allocateMemory/rtl_freeMemory.

	I'm really rather convinced that we shouldn't be piling up huge amounts
of exception unwind information, and crippling our optimiser by
terrifying it with lots of things that never really happen. At the most
banal level, I suspect that:

	struct Empty { int unused; };
	Empty *p = new Empty();
	delete p;

	can't legitimately be optimised away if we have a throwing constructor,
but of course I can dig out some compiler people who know what they're
on about here.

	Consistently calling std::abort() somewhere rather than waiting for a
SEGV sounds fine, though preferably not in-lined into many tens if not
hundreds of thousands of duplicate compare/branch/call-function sides at
every object construction.

	Compared with that sort of waste, using the CPU's beautiful, efficient,
built-in exception handling mechanism that requires zero code, and no
unwind table ;-) *((int *)NULL) = 42; makes some sense.

	I don't find the explanation that most C++ object allocation wastes
space left and right a great argument for doing yet more wastage :-)
indeed, having an allocator that does not throw sounds quite sensible to
me. The size of our binaries is already quite staggering given how
relatively little they do.

> Alternative, replace rtl_allocateMemory/rtl_freeMemory in strtmpl.cxx
> with new/delete, and remove the inline bad_alloc throwing from the
> header and assume that there isn't any existing users of the c-api that
> ever checked that rtl_uString2String failed

	I guess I now need to go and characterise how much of the saving is
from removing tens of thousands of in-lined 'if (baa) throw
std::bad_alloc();' calls vs. the exception unwind and knock-on optimiser
impact of having all that there.

	Sigh,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot