On Sunday, September 15, 2013 10:39:40 monarch_dodra wrote: > I have a few issues with ref counted. > > First, if you *ever* place one in an array or an AA, then you > will leak. It is NOT designed for simply incorporating reference, > but for deterministic finalization. > > Second, it has an elaborate postblit and opAssign. This is not a > big issue in itself, but their sole existence does cause dmd to > generate code that is sub-optimal. It also means it can't take > the "optimal" route in a lot of algorithms (array has to emplace > each element individually, for example). > > Finally, a RefCounted will implicitly cast to its payload. I > think this is *horrible*. Before you know it, the Payload will > have "jettisoned" its wrapper, and you'll be operating on your > value-type payload "raw". For example: > void foo(T t); > RefCounted!T myRecCounted; > foo(myRefCounted); //Passes. Oops! > > The workaround would be to either require explicit "get" to go > from ref counted to payload (breaking existing code), or to > entirelly wrap the RefCounted as a member inside the struct > (requires boilerplate code).
Yeah. RefCounted could/should definitely be improved, but the concept is essentially the same as smart_ptr in C++11. In many ways, smart pointers are far superior to using the GC, and I really think that we should do a better job of supporting them and promoting them. There are obviously plenty of cases where the GC is better or even necessary, but in many cases - particularly with objects - smart pointers are arguably a much better way to go. - Jonathan M Davis
