On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote:
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
BetterC sounds like a C language with tons of features from..
well actually...it sounds like a C language that fixes C's
shortcomings.
To get that point across it should maybe be called C2D Easy
Interop Language.
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
It is what it is and if what it is is the best tool to fix a
problem I would not hesitate to use it to that end.
But you make it sound like betterC _should only_ work if actual D
code is called otherwise stick with good old C. From the POV of a
C programmer most of what betterC offers is a net gain and
nothing is a loss because what are they losing by upgrading from
C? And in general not paying for something you don't use or need
is considered a gain, no?
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.
Please tell me. How would I disable just the Error mechanism, for
example ?
As far as I can tell it's not sufficient that I don't use nothrow
in my code because if it was used in phobos or druntime or some
other D code I'd have to deal with it.
But I know the answer to that. It's not possible because it was
never considered because why would anyone want to do that and
have the program just crash.
Let's say I don't want to deal with OutOfMemoryError. That means
essentially I'm losing the GC. Which sucks big time as it is
_the_ selling point for me to use D over C.
Let's say I didn't agree with RangeError for assoc. Arrays. I
imagine it allocates dynamically and hence has a dependency on
the GC so I have to consider the OutOfMemoryError headache even
if I would agree to RangeError. Solution again don't use it and
implement my own.
Really, I don't see the difference between not using a feature
and not having a feature available; result's the same - I need a
solution/replacement.
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
Looks like one can only choose the headache to deal with.
Now, from the point you make about betterC, it seems like a
better idea to abandon ship now and return to C instead of having
to deal with similar headaches with betterC in the future.
