Using D

[Rikki Cattermole via Digitalmars-d]

On 12/07/2014 12:10 p.m., Mike wrote:
> On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
>> I agree that the GC phobia is way, WAY, overblown for practical
>> programming.
>
> I agree with this, as well, but it's a generalization.
>
> There are some applications that the current GC is not suitable for, but
> D provides a plethora of features for disabling the GC or managing
> memory in other ways (very cool), so I don't see a reason to not use D
> even for the most demanding problem.  I love the GC for some things I
> do, but can't use it for other things I do.  For the vast majority of
> applications I see people using D for, however, I see no reason why
> there should be any worry about the GC.
>
> The problem, however, when managing one's own memory is that one cannot
> use some of the built-in types, like Exceptions, that are instantiated
> deep within the runtime.  A solution to this would likely quiet some of
> the clamoring, IMO.
>
> I would be interested in hearing any suggestions for disabling the GC
> and still making use of Exceptions, dynamic arrays, etc... using a
> user-supplied memory manager.  Maybe something like this already exists,
> and people like me just aren't aware of it.
>
> Being a novice still, I don't know what the solution is.  At the moment
> I exploring region-based memory management (nice example at
> http://en.wikipedia.org/wiki/Region-based_memory_management). I also saw
> some proposals for something like
> gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be nice.
>
> Mike

Something I've been thinking about is an overload for with statement.
E.g.

with(new MyAllocator) {
	void*[256] values;
	//...
}

class MyAllocator : IGC {
	private {
		IGC prevGC;
	}
	
	void opWithIn() {
		this.prevGC = GC.getImpl();
		GC.setImpl(this);
	}

	void opWithOut() {
		GC.setImpl(this.prevGC);
	}
}

Of course if we added an overload that allowed for passing root memory 
blocks that can be freed (ref countered guaranteed at compilation), we 
could force them to be freed in opWithOut. Otherwise tell the previous 
GC to use it.

Now I sort of mix GC and allocator up a little bit, but if it is done 
right. We could swap out the GC for an allocator and make it almost the 
same.

But in saying this, this would mean we would need to have a rethink of 
how we do the GC in druntime. At least from the architecture point of view.

This isn't the reason I thought of this, mostly because I was exploring 
how to do something like GWT nice (not really required but could be 
useful for caching output).

Its a small addition, that may pay off for this kind of work 
substantially. Unless of course we already have it? I didn't realize 
that statements worked in with statements till a couple days ago. So if 
not, I would be surprised.