TempAlloc: an unusual request

[KennyTM~]

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.