On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
> Obviously, nothrow documents the behavior of a function and is checked when the code is available to the compiler.
>
> At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

This is a bit old but anyway.

When you call functions which potentially throw, the compiler has to generate landing pads to handle exceptions if:

1. You have a catch block.
2. You have to call destructors.

This does not directly impact runtime performance but it bloats the executable code (and it will probably impact runtime performance because of caching).

I'm not a compiler expert, so take this with a grain of salt.

I found this very helpful to understand how exceptions work:

https://monoinfinito.wordpress.com/2013/04/23/c-exceptions-under-the-hood-14-multiple-landing-pads-the-teachings-of-the-guru/

I linked article 14 with landing pads but you should probably start at the beginning ;)

On Sun, Nov 08, 2020 at 10:00:28PM +0000, random via Digitalmars-d wrote:
> On Monday, 26 October 2020 at 18:47:41 UTC, Q. Schroll wrote:
[...]
> > At first glance, one could assume a nothrow function can save the compiler from the need to generate exception handling stuff for a function. But since nothrow doesn't mean the function won't throw, but merely that it won't throw an Exception, what optimizations does nothrow enable?

The reason it's a bad idea to catch Throwable is because the compiler is *not* obligated to generate exception handling stuff in nothrow functions, even if a Throwable ends up going through that function..


[...]
> When you call functions which potentially throw, the compiler has to generate landing pads to handle exceptions if:
> 
> 1. You have a catch block.
> 2. You have to call destructors.
> 
> This does not directly impact runtime performance but it bloats the executable code (and it will probably impact runtime performance because of caching).
[...]

Nothrow functions can have exception handling code elided. So in that case it will not incur the runtime cost.


T

-- 
Computers aren't intelligent; they only think they are.

On 11/8/20 6:53 PM, H. S. Teoh wrote:
> On Sun, Nov 08, 2020 at 10:00:28PM +0000, random via Digitalmars-d wrote: > [...]
>> When you call functions which potentially throw, the compiler has to
>> generate landing pads to handle exceptions if:
>>
>> 1. You have a catch block.
>> 2. You have to call destructors.
>>
>> This does not directly impact runtime performance but it bloats the
>> executable code (and it will probably impact runtime performance
>> because of caching).
> [...]
> 
> Nothrow functions can have exception handling code elided. So in that
> case it will not incur the runtime cost.

I think this is slightly incorrect. If you throw an Error inside a nothrow function, it will properly run destructors, and you can catch the Error inside the function.

I would say as well, if you catch an Error or Throwable resulting from a call to a nothrow function, it should always generate that handling code. But I think the spec is written such that it might elide the exception handling code (I don't see this ever happening).

The main case is when you *don't* catch Error or Exception when calling a nothrow function, and your code does cleanup via RAII, the cleanup will not happen.

-Steve