Jeremie Pelletier wrote:
Those new and better ways of doing things in programming languages might
imply semantics some programmers are not willing to use, and would
rather keep their older language and implement their own version of that
feature themselves, pure C will always dominate in that in my opinion
since I can't think of anything in the language itself that generate
calls to runtime methods,
There are several things that do - things like floating point
conversions, long division, etc.
which fortunately can also be done in D. A lot
of D features require runtime calls, not everyone is willing to dig into
the runtime to learn what such calls imply in terms of performance. For
example, I myself stay off scope() for real time code because I'm aware
it needs to call into _d_framehandler.
That's only called when handling an exception, not for just setting up
the frame and normally executing it. Also, if you annotate your
functions as "nothrow", and your guarded statements do not throw, the
compiler will elide the exception handling code.
- Re: How Nested Functions Work, part 2 Jeremie Pelletier
- IDEs and programming languages Walter Bright
- Re: IDEs and programming languages Jeremie Pelletier
- Re: IDEs and programming languages Bill Baxter
- Re: How Nested Functions Work, part 2 Walter Bright
- Re: How Nested Functions Work, part 2 Jeremie Pelletier
- Re: How Nested Functions Work, part 2 BCS
- Re: How Nested Functions Work, part 2 Jeremie Pelletier
- Re: How Nested Functions Work, part 2 Walter Bright
- Re: How Nested Functions Work, part 2 Jeremie Pelletier
- Re: How Nested Functions Work, part 2 Walter Bright
- Re: How Nested Functions Work, part 2 Jeremie Pelletier
- Re: How Nested Functions Work, part 2 Walter Bright
- Re: How Nested Functions Work, part 2 Lutger
- Re: How Nested Functions Work, part 2 Walter Bright