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)?
/** Optional: frees a chunk allocated with allocate */
static void free(void *p) {
.free(p);
}
/** Optional: frees all chunks allocated with allocate */
// static void freeAll();
/** Resizes a chunk allocated with allocate without moving.
Required, but may be implemented to always return false. */
static bool resize(void* p, size_t newSize) {
// Can't use realloc here
return false;
}
static void* realloc(void* p, size_t sz)?
/** true if calls to free enforce the pointer is valid */
enum { freeIsChecked = false }
[snip]
}
This is a symbolic interface. Some or all of the functions above may be
static. I think, without being yet positive, that the allocator should
have reference semantics, i.e. all copies of a given allocator should
manipulate the same memory. This should reduce unwitting errors caused
e.g. by passing an allocator by reference instead of by value.
For TempAlloc that means the primitives frameInit and frameFree are
replaced with an object, e.g. RegionAllocator. That object and all of
its copies manage a given frame. (BTW I think the name "region" is
consecrated and should replace "frame" throughout in TempAlloc. In fact
TempAlloc should be renamed to RegionAlloc.)
With this interface at hand I think we can tackle a variety of
heavy-duty allocation tasks in a relatively abstract manner. In
particular, we can compose several allocation strategies (e.g. a heap on
top of a region). A simpler task would be e.g. to define an aligned
allocator on top of an unaligned one.
Andrei
If core.memory.GC is to adopt the Mallocator interface, I think it's
better not to break backward compatibility without a good reason.
