On 06/19/2011 12:29 PM, KennyTM~ wrote:
On Jun 20, 11 00:07, Andrei Alexandrescu wrote:
On 6/19/11 5:03 AM, Lars T. Kyllingstad wrote:
On Sat, 18 Jun 2011 09:00:13 -0500, Andrei Alexandrescu wrote:
I'd like to kindly request the author, the review manager, and the
community that TempAlloc skips this round of reviews without inclusion
in Phobos, to be reviewed again later.
As review manager, I don't mind postponing the review until some later
time.
As a community member and Phobos user, I think it would of course be
preferable if TempAlloc fits into a more general allocator interface.
As an active TempAlloc user, I hope it doesn't take too long before said
interface is decided upon. ;)
-Lars
I'm thinking of defining a general interface that catches malloc, the
GC, scoped allocators a la TempAlloc, and possibly compound allocators a
la reaps.
I'll start with an example:
struct Mallocator
{
/** Allocates a chunk of size s. */
static void * allocate(size_t s) {
return enforce(malloc(s), new OutOfMemory);
}
static void* malloc(size_t s)?
We can use either the malloc/free nomenclature or the
allocate/deallocate nomenclature. I personally favor the latter so as to
not create confusion. The semantics of allocation may be quite different
from that of malloc.
static bool resize(void* p, size_t newSize) {
// Can't use realloc here
return false;
}
static void* realloc(void* p, size_t sz)?
No, resize is always in place unlike realloc.
If core.memory.GC is to adopt the Mallocator interface, I think it's
better not to break backward compatibility without a good reason.
Good point. Generally the GC allocator was intended quite specifically
for GC, but the closer we get the APIs together, the better. Probably
the allocator interface should have a notion of type and type-specific
allocation attributes.
Andrei
