| |
| Posted by Siarhei Siamashka in reply to Bastiaan Veelo | PermalinkReply |
|
Siarhei Siamashka
Posted in reply to Bastiaan Veelo
| On Friday, 15 December 2023 at 10:53:44 UTC, Bastiaan Veelo wrote:
> On Thursday, 14 December 2023 at 18:26:40 UTC, Siarhei Siamashka wrote:
> On Thursday, 14 December 2023 at 18:18:21 UTC, matheus wrote:
> Allocate();
GC.disable();
run_the_game();
GC.enable();
Is the run_the_game() part of code supposed to be annotated with the @nogc attribute?
It depends, I guess. If it is not @nogc annotated, it can still allocate and if it does it can run out of memory, unless it calls GC.collect at the right moments. If it is @nogc annotated, it cannot allocate and then the whole GC.disable and GC.enable become unnecessary.
That's exactly my concern and the compiler isn't very helpful in this scenario.
Would it be useful to have something like @vettedgc attribute, for annotating the part of code, where each GC allocation needs to be pedantically reported by the compiler as a warning? And some sort of @permitgc attribute to suppress these warning in a few selected places inside of this code if really necessary?
I would suggest to maybe somehow differentiate between "hard" @nogc variety, where the garbage collector isn't even linked at all. And "soft" @nogc variety, where GC allocations are generally strongly discouraged, but allowed as explicitly annotated exceptions in a few selected places after careful review. The former is useful for hardcore bare metal embedded use cases and that's what the compiler supports right now. The latter would be maybe useful for game developers.
|