Leave GC collection to the user of the D library?
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sun May 9 16:57:02 UTC 2021
On Sunday, 9 May 2021 at 16:29:12 UTC, IGotD- wrote:
> I see it as a special case where memory management is bounded
> to a certain primitive/ways of programming. Also a pool for
> each possible primitive will increase the meta data.
What do you mean by meta data in this context? I think it should
resolve at compile time?
Yes, it does imply a programming model if you want GC, but it
should allow the programmer to write his own scheduler for
flexibility. You would still need RC between tasks...
> Some in that thread mention that D must head towards RC and
> that's what my opinion is as well. As Walter do not want to
> make a special fat pointer type, at least making
> Phobos/druntime using RC internally would be a step in the
> right direction.
The problem of not having a fat pointer type is when you have
arrays of objects. Then you cannot have a RC counter on a
negative offset, so you will be forced to embed it in all objects
(whether RC-managed or not).
It can be mitigated by requiring that all owning pointers to
arrays must be a RC-slice and not a RC-pointer. Then you have a
RC-slice of static length 1. (shrug)
More information about the Digitalmars-d
mailing list