why allocators are not discussed here

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Jun 25 16:08:26 PDT 2013


On Wed, Jun 26, 2013 at 12:50:36AM +0200, Adam D. Ruppe wrote:
> On Tuesday, 25 June 2013 at 22:22:09 UTC, cybervadim wrote:
> >(introducing a new keyword allocator)
> 
> It would be easier to just pass an allocator object that provides
> the necessary methods and don't use new at all. (I kinda wish new
> wasn't in the language. It'd make this a little more consistent.)

It's not too late to introduce a default allocator object that maps to
built-in GC primitives. Maybe something like:

	struct DefaultAllocator
	{
		T* alloc(T, A...)(A args) {
			return new T(args);
		}
		void free(T)(T* ref) {
			// no-op
		}
	}

We can then change Phobos to always use allocator.alloc and
allocator.free, which it gets from user code somehow, and in the default
case it would do the Right Thing.


> The allocator's create function could also return wrapped types,
> like RefCounted!T or NotNull!T depending on what it does.

So maybe something like:

	struct RefCountedAllocator
	{
		RefCounted!T alloc(T, A...)(A args) {
			return allocRefCounted(args);
		}
		void free(T)(RefCounted!T ref) {
			dotDotDotMagic(ref);
		}
	}

etc..


> Though the devil is in the details here and I don't think I can say
> more without trying to actually do it.

The main issue I see is how *not* to get stuck in C++'s situation where
you have to specify allocator objects everywhere, which is highly
inconvenient and liable for people to avoid using, which defeats the
purpose of having allocators. It would be nice, IMO, if we can somehow
let the user specify a custom allocator for, say, the whole of Phobos,
so that people who care about this sorta thing can just replace the GC
wholesale and then use Phobos to their hearts' content without having to
manually specify allocator objects everywhere and risk forgetting a
single case that eventually leads to memory leakage.


T

-- 
Computers shouldn't beep through the keyhole.


More information about the Digitalmars-d mailing list