A naive attempt at a refcounted class proxy

ketmar via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Jan 13 10:19:31 PST 2015


On Tue, 13 Jan 2015 18:12:44 +0000
aldanor via Digitalmars-d-learn <digitalmars-d-learn at puremagic.com>
wrote:

> On Tuesday, 13 January 2015 at 16:43:09 UTC, ketmar via 
> Digitalmars-d-learn wrote:
> > On Tue, 13 Jan 2015 16:17:51 +0000
> > aldanor via Digitalmars-d-learn 
> > <digitalmars-d-learn at puremagic.com>
> > wrote:
> >
> >> This discussion: 
> >> http://forum.dlang.org/thread/bqtcdpsopxmnfbjyrrzf@forum.dlang.org 
> >> -- led me wondering if it would be possible to create some 
> >> crippled version of a class proxy that is based on RefCounted 
> >> and came up with something like this:
> >> 
> >> struct Box(T) if (is(T == class)) {
> >>      @disable this();
> >> 
> >>      this(Args...)(Args args) {
> >>          _payload._refCounted.initialize(new T(args));
> >>      }
> >> 
> >>      private {
> >>          struct _Box(T) {
> >>              private T _instance;
> >> 
> >>              ~this() {
> >>                  destroy(_instance);
> >>              }
> >>          }
> >>          RefCounted!(_Box!T) _payload;
> >>      }
> >> 
> >>      ~this() {
> >>      }
> >> 
> >>      auto opDispatch(string name, Args...)(Args args) {
> >>          return 
> >> mixin("_payload._instance.%s(args)".format(name));
> >>      }
> >> }
> >> 
> >> which lets you create Box!SomeClass(args) and it will be 
> >> refcounted unless you escape references and do other weird 
> >> stuff.
> >> 
> >> It actually sort of seems to work at first glance, at least it 
> >> seems like it does... But with my D experience being fairly 
> >> limited I wonder what the potential pitfalls would be?
> >> 
> >> Full source code with example and stdout:
> >> https://gist.github.com/aldanor/d5fb5e45ddf3dd2cb642
> > it's not that hard to make a boxed class. what is really hard 
> > is to
> > make functions that expects the class itself to accept it's 
> > boxed
> > variant too and behave correctly with it.
> >
> > either you have to unbox it (and then hope that it will not 
> > leak), or
> > write two set of functions, for "real" class and for boxed one. 
> > and
> > then you may want to inherit from your class and pass that 
> > inherited
> > class to one of the functions... and now you have three sets. 
> > and so
> > on...
> >
> > as structs can't be inherited, there is no such problem for 
> > structs.
> 
> That's completely valid. Where it would work though, I think, is 
> if all classes are private/package and only expect/return boxed 
> classes and never the references. This way you sort of get 
> multiple inheritance (for the internal implementation) without 
> polymorphism, but with value semantics and ref counting for the 
> outward interface.
and then you can go with structures in the first place, i think.
remember that you have that k00l `alias this` trick for them!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20150113/508775f8/attachment.sig>


More information about the Digitalmars-d-learn mailing list