std.allocator needs your help

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Sep 23 17:03:00 PDT 2013


On Mon, Sep 23, 2013 at 07:29:39PM -0400, Nick Sabalausky wrote:
> On Mon, 23 Sep 2013 17:02:09 +0200
> "Adam D. Ruppe" <destructionator at gmail.com> wrote:
> 
> > We should really deprecate the new keyword. It'd break like all 
> > code ever, but with D's templates, there's no need for it, and 
> > when it is there, it is going to spark problems about replacing 
> > global allocators or the library allocators being second class 
> > citizens.
> > 
> 
> I think that's addressing the wrong problem, it wouldn't solve much,
> if anything. We'd just end up with a lot of lib writers (and others)
> hardcoding in usage of the default allocator. So it'd be exactly the
> same as now, just with uglier syntax and a ton of breakage.
> 
> What's ultimately needed is a way to change the default allocator for
> not only "new" but also array concatenation, closures, and any other
> part of the language that might allocate. That way, we actually *do* get
> the benefits we're looking for, plus we keep the nicer current syntax
> and no breakage.
> 
> tl;dr: "new" is a red herring. The real issue is being able to easily
> replace the default allocator.

I thought Walter's DIP already addresses the issue of replacing the
default allocator?

	http://wiki.dlang.org/DIP46

I get the feeling that we don't have a good handle on the fundamental
issues, though. Having a stack for managing the default allocator works
for the simpler cases, but it's unclear how things would interact once
you throw in other requirements, like class/struct-scoped allocators,
block scoped allocators inside closures, user-specified allocators that
must interact with the foregoing, etc..

For example, it's relatively easy to understand this:

	void doWork() {
		gc_push(MyAlloc);
		scope(exit) gc_pop();
		... // do work
	}
	void doMoreWork() {
		gc_push(AnotherAlloc);
		scope(exit) gc_pop();
		... // do work
	}
	void main() {
		doWork();
		doMoreWork();
	}

But once you throw in closures and delegates, things become rather murky:

	auto getCallback() {
		gc_push(MyAlloc);
		scope(exit) gc_pop();

		int closed_var;
		return {
			// What does this do?
			closed_var++;

			string x = "abc";
			x ~= "def"; // which allocator does this use?
		};
	}
	void main() {
		auto dg = getCallback();
		gc_push(OtherAlloc);
		scope(exit) gc_pop();
		dg();		// Hmm...
	}


T

-- 
May you live all the days of your life. -- Jonathan Swift


More information about the Digitalmars-d mailing list