Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Monday 15 of July 2013, Bjoern Michaelsen wrote:
Hi,

a quick git grep suggests that we use gb_Library_add_noexception_objects
only once, thus I dont expect the original reason for keeping support for
this (possibly better performance and smaller binaries by skipping stack
unwinding logic) to be manifesting anymore for us.

 At least with GCC there should not be any performance different 
for -fexceptions vs -fno-exceptions code, except for the size of the binary. 
It is a major contributing factor to the binary size though (10-20% IIRC). No 
idea about MSVC.

As compiling some special-cased C++ objects without exception support,
while the majority supports exceptions might lead to confusing during
debugging, should we kill gb_Library_add_noexception_objects completely and
only support C++ with exceptions. Note that if there really is code that
has huge wins from not having exception handling, having those in plain old
C is still possible.

 I seem to remember a discussion where it was said that C building could be 
dropped, since building plain old C files as C++ is possible :).

So in the interest of the principle of least surprise, can we always have
exception handling for C++ code? Opinions?

 Given that's it's practically unused, the answer appears to be simple. If 
somebody in the future will be willing to spend the time working on this 
optimization, they can bring it back.

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.