TempAlloc: an unusual request

Robert Jacques sandford at jhu.edu
Mon Jun 20 20:12:54 PDT 2011


On Sun, 19 Jun 2011 12:07:20 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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);
>      }
>
>      /** 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;
>      }

I think resize should behave like/named-after GC.extend: static size_t  
extend(void* p, size_t mx, size_t sz);


More information about the Digitalmars-d mailing list