Eliminate class allocators and deallocators?

[Michel Fortin]

On 2009-10-07 17:53:21 -0400, Craig Black <cblack at ara.com> said:

>> Yes, recycling is best and I'm considering it. I'm only worried about
>> the extra cost.
>> 
>> Andrei
> 
> No this is a bad idea.  Removing the possibility to delete data will 
> cause serious problems with heap fragmentation in some programs.

Hum, perhaps we need to review more thoroughly how memory allocation 
works. As Andrei said himself, we now have all the necessary parts in 
the language to reimplement 'new' as a library function.

So let's say we ditch 'new' and 'delete' as keywords. Let's first 
replace the keyword 'new' with a static function of the same name in a 
class or a struct. It could be implemented this way:

	static T new(A...)(A a) {
		T t = GC.alloc!T(); // GC.alloc sets the T.init bits.
		t.__ctor(a);
		return t;
	}

Usage:

	Foo foo = Foo.new();

That's a static function template that needs to be reimplemented for 
every subclass (Andrei already proposed such kind of mixins) and that 
returns a garbage-collected object reference. Now, if you want manual 
allocation:

	static T new(A...)(A a) {
		T t = GC.allocNoCollect!T(); // GC won't collect this bit.
		t.__ctor(a);
		return t;
	}

	void dispose() {
		this.__dtor();
		GC.free(this);
	}

Usage:

	Foo foo = Foo.new();
	...
	foo.dispose();

But then you could do much better: 'new' could return a different type: 
a smart reference-counted pointer struct for instance. The 
possibilities are endless.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/