TempAlloc: an unusual request

[KennyTM~]

On Jun 20, 11 02:57, Andrei Alexandrescu wrote:
> 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.

I see. Meaning something like GC.extend.

>
>> 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

BTW, maybe we should start a new thread on this.