On Wednesday, 7 October 2015 at 15:30:17 UTC, Jonathan M Davis
wrote:
On Wednesday, 7 October 2015 at 12:59:05 UTC, bitwise wrote:
On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz
wrote:
RefCounted isn't implemented for classes, but there's no
reason why it shouldn't work.
Really, I don't get why everyone wants to have builtin
refcounting, when all that's required is a working way to
make escape-proof references.
If you make a class that owns a resources that needs
deterministic destruction, there is no guarantee that everyone
will wrap that class in a RefCounted properly. Also, I've
already stated many more problems with struct wrappers.
Except it doesn't even matter if they always wrap it properly -
or even if something like DIP 74 is implemented. The core
problem is that no object (be it struct or class) which needs
deterministic destruction can have its lifetime managed by the
GC - be it be simply being directly allocated by the GC or by
sitting inside of an object that was put on the GC heap without
any kind of ref-counting.
With DIP74, the ref counting is hard coded into the type itself.
The intention of the original author of the class is inseparable
from the code. The same is not true for a class that is simply
"meant" to be used in a context where it has deterministic
destruction.
So if I was a graphics programmer, and awake of this
issue(deterministic destruction), I could open up a class and
just look for opRelease() rather than having to try and reason
about it's usage.
The programmer is always going to have to be careful about
where they put an object that needs deterministic destruction.
Again, it's much easier to be careful about this when the
author's intent is baked into the class.
Regardless of the ref-counting mechanism though, you can't
guarantee that it's going to be used correctly. The best that
we can do is guarantee that if it is used correctly, then the
object will be destroyed deterministically.
Since you're probably going to make me repeat myself anyways, I
might as well get it out of the way ;)
Again, it's much easier to be careful about this when the
author's intent is baked into the class.
Bit
