There are legitimate uses cases when you can't afford the runtime
machinery (attach/detach every incoming thread in a shared
library), more than not being able to afford the GC from a
performance point of view.
GC gives you higher productivity and better performance with the
time gained.
Now, @nogc code is good for performance since (even in a GC
program) you will have no hidden allocation anymore, if you also
disable postBlut and copy ctor, unlike in C++ where hidden copies
are rempant.
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
What are your thoughts about using GC as a library writer?
I don't use it always, but wish I could do it.
Meanwhile, I make plenty of nothrow @nogc code.
On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:
If you wan't to include a library into your project aren't you
more inclined to use a library which is gc free?
Yes I am, but my needs are very specific and only the "betterC"
subset fits it, and it's certainly not the nominal case in D, nor
should it be. Some of the D target have strict requirements, for
example Hipreme engine use audio-formats (nothrow @nogc), but
audio-formats uses exceptions internally, maybe that will be an
issue, depending on the flavour of D runtime it uses.
