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