What is the point of nothrow?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sat Jun 16 21:25:01 UTC 2018


On Saturday, June 16, 2018 18:45:53 wjoe via Digitalmars-d-learn wrote:
> What you said earlier:
>
> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> > [...]
> >
> > 2. If the compiler knows that a function can't throw an
> > Exception, then it doesn't have to insert any of the Exception
> > handling mechanism stuff [...] So, the fact that a function is
> > nothrow gives you a performance benefit, [...]
> >
> > - Jonathan M Davis
>
> made me believe that performance is one of the major reasons to
> use it. No?
>
>  From the betterC page https://dlang.org/spec/betterc.html section
> 40.2:
> ---
> Not Available
>
> D features not available with BetterC:
>
>      Garbage Collection
>      TypeInfo and ModuleInfo
>      Classes
>      Built-in threading (e.g. core.thread)
>      Dynamic arrays (though slices of static arrays work) and
> associative arrays
>      Exceptions
>      switch with strings
>      final switch
>      synchronized and core.sync
>      Static module constructors or destructors
>      Struct destructors
>      unittest (testing can be done without the -betterC flag)
> ---
> Apart from a few convenience features lost this list reads like a
> shopping list for performance gain over full fledged D, in the
> spirit of nothrow omitting exception handling mechanism, to me.
> You gain from no garbage collection overhead, no vtable overhead,
> no RTTI overhead, no exception overhead, etc, etc, ...
>
> Back in the late 90ies I used to write the lion's share of code
> in Pascal and implement mission critical algorithms in asm.
> Worked back then why wouldn't it work today, except that I
> wouldn't use asm anymore but something like C or betterC.
>
> Thus, people who need this kind of performance boost can benefit
> 2 fold from using betterC.
> 1. They get to keep most of D's awesomeness, including compile
> time features, scope statements, RAII, lack of a pre processor,
> memory safety protections and complete meta programming, are just
> _some_ of the highlights. And on the other hand
> 2. they gain by getting rid of a lot the 'performance hogs' like
> GC, exceptions and more, right?
> And, with no exceptions altogether they do not need to worry
> about it at all.
>
> I'm sold!

The _entire_ point of betterC is to be able to call D code from C code
without having to deal with druntime (you can call D code from C code even
without betterC, but then you have to worry about initializing and shutting
down druntime). Basically every feature that you can't use in betterC is
considered a loss, and efforts are being made to make more of them work.
There's always going to be a limit to that, and some D features just plain
require druntime (just like some of C++'s features require a runtime), but
it was never the point of betterC to strip out a bunch of D features. That's
just the natural consequence of the goal of being callable from C code
without needing to worry about druntime.

All of those features that betterC can't use can be avoided in normal D code
if you don't want them for whatever reason. nothrow is actually one of the
few cases where you have to explicitly do something in order to avoid that
list of features that you have there. In the other cases, you just don't use
the feature, and the only cost you're paying is the startup and shutdown
time for druntime and the few resources that it uses.

So, while you might choose to use betterC over concerns about the
performance of D features that betterC doesn't allow, that was never the
point of betterC.

- Jonathan M Davis



More information about the Digitalmars-d-learn mailing list