On Tue, 2012-02-28 at 14:48 +0100, Lubos Lunak wrote:
> Speaking of the size at the call-site, I good part is the code trying to
> throw std::bad_alloc in case the allocation fails. That actually looks rather
> useless to me, for several reasons:
>
> - not all OUString methods check for this anyway
> - rtl_uString* functions do OSL_ASSERT() after allocations
> - with today's systems (overcommitting, etc.) it is rather pointless to guard
> against allocation failures
>
> Does somebody see a good reason not to just remove it?
Not me :-) I'd love to kill that cruft. Of course, on the very rare
occasions that we do a huge allocation for a string - perhaps we store
an entire VBA module in a single string or something silly ;-) which
might reasonably fail, then no doubt we could use the native C method,
and act accordingly if it failed.
So - I'd love to remove this compound source of bloat and if we're
indeed deeply worried about out of memory crashes, then doing a better
job of logging and journaling user input as it's entered so we can
replay it later if necessary ;-)
ATB,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
