Re: size of exception handling

["Moritz Strübe" <moritz.struebe@redheads.de>]

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.struebe@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843