minutes of ESC call ...

[Stephan Bergmann]

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