Containers
rikki cattermole
rikki at cattermole.co.nz
Tue Aug 31 17:27:37 UTC 2021
On 01/09/2021 5:21 AM, deadalnix wrote:
> - Not expose much of its internals. This like iterators being raw
> pointers (or the result of using the in operator) for instance, impose
> constraint on the internal that almost always end up costing a ton of
> perf as new techniques are discovered (recent exemples include open
> addressing with SSE probing for instance). All of this needs to be wrapped.
Something I'm doing with my own containers is to create a "custom
reference" around the internals.
```
struct Thing {
this(RCISharedAllocator allocator) {
this.impl = allocator.make!ThingImpl(allocator);
}
this(ref Thing other) {
this.impl = other.impl;
if (this.impl !is null)
atomicOp!"+="(this.impl.refCount, 1);
}
~this() {
if (this.impl !is null) {
if (atomicOp!"-="(this.impl.refCount, 1) == 0) {
RCISharedAllocator allocator = this.impl.allocator;
allocator.dispose(this.impl);
}
}
}
@safe:
bool isNull() { return impl is null; }
private:
ThingImpl* impl;
}
private:
struct ThingImpl {
@safe:
RCISharedAllocator allocator;
shared(size_t) refCount;
}
```
I've found this to work quite well.
More information about the Digitalmars-d
mailing list