On 10/9/2013 9:45 PM, Manu wrote:
The are a few problems with mangling the type;
I don't understand that.
It breaks when you need to interact with libraries.
That's true if the library persists copies of the data. But I think it's doable if the library API is stateless, i.e. 'pure'.
It's incompatible with struct alignment, and changes the struct size. These are very carefully managed properties of structures.
Nobody says there can be only one variant of RefCounted.
It obscures/complicates generic code.
It seems to not be a problem in C++ with shared_ptr<T>.
It doesn't deal with circular references, which people keep bringing up as a very important problem.
ARC doesn't deal with it automatically, either, it requires the user to insert weak pointers at the right places.
But, if the RefCounted data is actually allocated on the GC heap, an eventual GC sweep will delete them.
What happens when a library receives a T* arg? Micro managing the ref-count at library boundaries sounds like a lot more trouble than manual memory management.
Aside from purity mentioned above, another way to deal with that is to encapsulate uses of a RefCounted data structure so that raw pointers into it are unnecessary.
