Re: minutes of ESC call ...

On 03/29/2012 06:46 PM, Michael Meeks wrote:
> * exception size stats (Caolan)
>         + likes exceptions, but they are big
>         + trade-off - bigger tables for smaller code ?
>         + new constructors in 3.6 - work on string literals
>                 + shouldn't have to throw - small strings
>         + not strings controlled by malicious input (Stephan)
>                 + we abort anyway in these cases
> AA:     + drop exception specs from new string constructors (Lubos)
>         + drop from Any / small object allocations as interested

Just to clarify:  The decision whether to trade "throw std::bad_alloc" 
for "std::abort()" should be based on whether calling code wants to 
handle the out-of-memory situation (i.e., catch the bad_alloc).

For Lubos' new string-from-literal constructors, the case is pretty 
clear:  If such strings cannot be allocated, memory has run so low that 
the application cannot meaningfully operate any longer, anyway.

For other string constructors, the question is whether there /is/ code 
that, say, reads data from a user-supplied document and creates strings 
from it, so could be fooled into trying to create excessively large 
strings, but also establishes an exception handler that abandons loading 
the document.  What I wanted to say on the call is that /if/ there is no 
such code anyway, then we can probably turn existing "throw 
std::bad_alloc" into "std::abort()" without loss of functionality (but 
with a gain in reducing object size).

Stephan