minutes of ESC call ...
sbergman at redhat.com
Fri Mar 30 00:46:50 PDT 2012
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).
More information about the LibreOffice