On 09/07/2011 10:37 PM, dsimcha wrote:
== 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.
The last allocated one is the array I append to in 80% or more of all
cases. A simple implementation in terms of resize should be really easy
in case an allocator cannot provide specially optimized code.
Would there be a way to implement an efficient appender on top of
RegionAlloc that would match the efficiency of having it in the interface?
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.
Does the standard allocator interface guarantee 16-byte alignment?
