make a nothrow call a throwing function

monarch_dodra monarchdodra at gmail.com
Thu Feb 7 14:14:51 PST 2013


On Thursday, 7 February 2013 at 21:32:28 UTC, Jonathan M Davis 
wrote:
> On Thursday, February 07, 2013 21:46:21 Maxim Fomin wrote:
>> So, you want to call function (which throws) from function 
>> marked
>> as nothrow? It seems to be breaking idea of what nothrow does.
>
> I believe that the problem is that the function isn't marked 
> nothrow even
> though it doesn't throw. He essentially wants to be able to 
> make the compiler
> treat it as nothrow at the call site (since he can't change the 
> function
> definition) without any overhead, and I don't think that that's 
> actually
> possible.

I was though able to get a function pointer, and cast said 
pointer, at compile time (place it an enum). At that point, 
calling the function via the compile-time known pointer *should* 
be just as efficient as calling the function directly. I'll need 
to check the assembly.

EG:

//----
import std.stdio;

void bar()
{writeln("bar");}

void foo() nothrow
{
     enum barnothrow = cast(void function() nothrow)(&bar);
     barnothrow();
}

void main()
{foo();}
//----

Yes, writeln actually can throw, so it's a bad example, but a 
proof. I'd be surprised if there was any run-time overhead (but I 
could be wrong).

In my case though, there is an extra overhead that I can't get a 
function pointer to dup, so I have to create an intermediary 
function. Depending on the inlined-ness of things, *that* may or 
may not incur an overhead.

> The normal way to handle cases where you know that a function 
> won't throw but
> isn't nothrow is to wrap it in a try block and put an assert(0) 
> statement in
> the catch block. That does incur some amound of overhead, but I 
> don't know how
> much. Apparently, monarch_dodra thinks that it's too much for 
> what he's doing
> though.
>
> - Jonathan M Davis

Well, I don't think it's too much, but wanted to know the 
alternatives. I like to know my options, and their costs. It 
costs nothing to ask, and you never know what you'll learn.

I think the conclusion I came to though is to bite the bullet, 
and not worry too about it.

Thank you for your answers anyways.


More information about the Digitalmars-d-learn mailing list