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
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
