Eliminate class allocators and deallocators?

Michel Fortin michel.fortin at michelf.com
Thu Oct 8 04:57:06 PDT 2009


On 2009-10-08 05:00:03 -0400, Chris Nicholson-Sauls 
<ibisbasenji at gmail.com> said:

> class C {...}
> 
> C new (T:C, A...) (A a) {
>      auto c = GC.alloc!T();
>      c.__ctor(a);
>      return c;
> }
> 
> auto somevar = new! C (1, 2, 3);

Nice idea, and it can already work... as long as your constructor is 
public (or you have private access from the module the template is 
defined in).


> // free-listed
> class F {...}
> 
> F new (T:F, A...) (A a) {
>      return F.List.length != 0
>          ? F.List.pop
>          : defaultNew! F (a)
>      ;
> }
> 
> The latter examples shows my thinking: that the stdlib/druntime could 
> easily provide a default new() that does what the current new operator 
> does. Class designers could then overload this default new() as needed. 
>  Provide a reasonable alias for the standard new() (I used "defaultNew" 
> above, but its probably not the best) and it can still be used as 
> backup in custom functions, such as in the free-list example.

What about 'newGarbageCollected!F' (or 'newGC!F' for short)?


> Incidentally... does anyone else notice that, in the static-new 
> proposal, we've once again recreated Ruby?
> 
> Proposed D2:
> auto foo = Foo.new;
> 
> Ruby:
> foo = Foo.new

Ah! I knew I had seen this pattern somewhere. Personally, I had more in 
mind the object instanciation pattern in Objective-C:

	NSString *s = [[NSString alloc] init];

and decided to combine that alloc & init pair (GC.alloc & __ctor in D) 
into 'new'.


> At least mine looks more like current syntax:
> auto foo = new! Foo;

I'd call this a marginal gain, but a gain nonetheless. A bigger gain of 
'new!Foo' over 'Foo.new' is that it lets users invent their own 
allocation method without having to change any class or struct.

But it'd require some changes to how protection attributes are handled 
in templates, because right now it just won't work with a non-public 
contructor.


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




More information about the Digitalmars-d mailing list