== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
> On 09/07/2011 09:48 PM, dsimcha wrote:
> > Thanks for taking the time to do this review. I appreciate the effort and
> > the
> > constructive criticism.
> >
> > == Quote from Christophe (trav...@phare.normalesup.org)'s article
> >> Concerning the gcallocator API, why is there no template method that
> >> forwards to new T? Is the user obliged to call allocate, and then
> >> initialise the object manually?
> >
> > Several people have asked this and I think it needs to be added. It's
> > obviously
> > trivial to implement, but I'm not really sure what to call it yet.
> > [snip.]
> 'create' has been suggested and seems reasonable.
> (personally I would prefer 'New' though.)
Sounds good.
> Another thing: I sometimes write code like the following:
> T[] x;
> while(some_condition(...)) {
> some_processing();
> x ~= some_function(...);
> }
> i.e. the length of the array is not known exactly in advance. I think
> that is a legitimate use case for an allocator, and the GC supports it
> natively. (but using std.array.appender can make it faster in some cases)
> Shouldn't this be part of the allocator interface? RegionAllocator would
> probably be really efficient on that.
Hmm, I'll think about that. When it comes to the balance between making
allocators powerful vs. simple, focused and easy to write, I think array
appending
is borderline. It would also get messy in the case of RegionAllocator because
you
could only append to the last allocated array.
> Also, if we have a GCAlloc and a RegionAlloc, a simple MallocAlloc could
> be useful too.
This is a todo for eventually. I was going to do it, but ran into some issues
about not knowing things like what alignment different platforms' malloc
guarantees.
