Am 12.05.2020 um 11:44 schrieb Freddie Chopin:
Would you use it if switching from -fno-exceptions to this new
approach
resulted in an immediate 20% code size increase, without actually
using
the new error handling feature at all? What about 10%?
I don't think that it will be that much. I agree with Freddie:
Exceptions are critical errors you need to handle anyway. Thus the code
size should not increase as the error-handling code should already be
there.
I can really recommend Herb's talk:
https://www.youtube.com/watch?v=ARYP83yNAWk , where also talks about
reducing RTTI overhead and making the C++-lib mostly exception free.
In that talk he mentions that it would be possible using some CPU-Bit to
return the state. This could result in adding a single instruction for
each call (ret/jmp if bit is set) and maybe a second to clear that flag.
Considering that you normally have to use at least an extra byte to pass
this information, which then needs to be evaluated, using
Herbcexceptions might actually result in smaller code than using manual
error handling. You still need run-time type information for catching,
but I'm sure that there are solutions for that, too (e.g. Herb's
solution from the talk *).
Cheers
Morty
* Alternatively it could be possible to only add type information that
is necessary for catching and only for types that can actually be thrown
(as far as I can see, all exceptions types must be known at link-time,
as they are constructed by the throw-expression).
--
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg
Telefon: +49 (0)911 180778-50
E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de
Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843
