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