On Tuesday, 3 March 2015 at 09:58:12 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 12:53 AM, Volodymyr wrote:
On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei
Alexandrescu wrote:
http://wiki.dlang.org/DIP74 got to reviewable form. Please
destroy and
discuss.
Thanks,
Andrei
With opAddRef/opRelease class does respondible for its
dealocation and
its own payload so breaks SOLID's single responsibility
principle.
Correct. That's a tactical matter that can be addressed e.g.
with mixin templates.
As
for me better design will be to do it closer to C++'s
shared_ptr.
e.g:
// maybe with @arc
struct RefCounter(T)
{
void opAddRef();
void opRelease();
ref T obj;
ref size_t count;
}
}
RefCounter!Widged myRefToWidget;
RefCounter with default ctor/dtor. opAddRef and opRelease is
for
compiler optimtimisation and elimination of redunadant ref
counter
increment/decrement.
We couldn't make that work with safety.
Andrei
Why couldn't? Let's for all @return (this) functions make
wrappers that rerturn RefCounter!MemberType(member,
ownerCounterPtr), and same thing for public fields
The wrapper nedded only for realy owned resources (but not simple
gc's refs).
