On Monday, 23 February 2015 at 15:35:52 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 23 February 2015 at 14:56:11 UTC, Marc Schütz wrote:
violation of the principle of separation of concerns: a
consumer shouldn't need to have information about the
management strategy, it should work equally with
`RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it
doesn't take ownership of the resource.
Just be aware that by not making the refcount part of C you
either:
1. Need one more indirection.
2. Need a more complicated allocator to avoid alignment padding
when C has 32byte/64 byte alignment requirements.
3. Risk having the refcount landing on a different cacheline,
causing more cache misses.
The refcount would be embedded right next to the object by the
constructor of `RefCounted!C`, which is responsible for
allocating memory for it, using an appropriate allocator.
If you do excessive refcounting (ARC) and care about
performance you actually need to let the implementor of C
decide where the RC_counter is embedded...
Of course there can be an additional (template) parameter to
`RefCounted`, or it could be a different, user-implemented type
altogether.
But my point was that all of `Unique!C`, `RefCounted!C` and `C`
should decay to `scope C`. This way, most consumers don't need to
be aware of the actual wrapper type (if any) at all.
