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

On 03/05/2012 04:29 PM, Michael Meeks wrote:
> 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

What's "we" and "our" here?  This looks to me like trying to fight a 
given (LO is implemented in C++; C++ makes use of exceptions -- just 
look at the standard library).  Stop worrying and learn to love the 
bomb.  ;)

> 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,

Where does a "throwing constructor" come into play here?  Do you mean a 
throwing operator new?  (If that is global operator new, it cannot be 
optimized away, without complete program analysis anyway, as global 
operator new/delete can be overridden by client code.)

> 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.

Again, the thousands of duplicates typically fold into a single instance 
per .so, so not that much excess space-wise.

>         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.

Only if you do not want to react to the exception.

>         I don't find the explanation that most C++ object allocation wastes
> space left and right a great argument for doing yet more wastage :-)

Not sure what you mean here.

Stephan