TempAlloc: an unusual request

[Andrei Alexandrescu]

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