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