I'm working on retrofitting TempAlloc (renamed to RegionAllocator)to fit Andrei's proposed allocator interface.  One issue I've run into is, what happens when a scoped allocator is returned from a function?  For example:

RegionAllocator fun() {
     RegionAllocator alloc;
     alloc.malloc(42);

     RegionAllocator alloc2;
     alloc2.malloc(42);
     return alloc2;
}

Now, alloc has died and alloc2 is still alive, violating LIFO requirements.  Since it's virtually impossible to do by mistake, I'm inclined to just make returning a RegionAllocator from a function after another one has been subsequently created undefined behavior.

Also, while we're on the subject, does anyone have any serious objections to me keeping frameInit/regionInit and frameFree/regionFree (they've been renamed) public but undocumented?  I need to write a wrapper around this new interface to simulate the old interface and avoid breaking a whole bunch of old code I've written.  I don't see any way to do this without these functions exposed.  Furthermore, they might be useful to people looking to build their own policies on top of RegionAllocator's low-level mechanisms.  Generally I believe that stable low-level features should be exposed to avoid ugly abstraction inversions.

>________________________________
>From: David Simcha <dsimcha at gmail.com>
>
>I'm working on retrofitting TempAlloc (renamed to RegionAllocator)to fit Andrei's proposed allocator interface.? One issue I've run into is, what happens when a scoped allocator is returned from a function?? For example:
>
>RegionAllocator fun() {
>? ? RegionAllocator alloc;
>? ? alloc.malloc(42);
>
>? ? RegionAllocator alloc2;
>? ? alloc2.malloc(42);
>? ? return alloc2;
>}
>
>Now, alloc has died and alloc2 is still alive, violating LIFO requirements.? Since it's virtually impossible to do by mistake, I'm inclined to just make returning a RegionAllocator from a function after another one has been subsequently created undefined behavior.

Can RegionAllocator check on postblit (called during return? not sure) at least in debug mode whether it's valid or not.? I think this might solve the problem.

-Steve

I already solved it, actually, with an extra check on destroying a region. If the last copy of an old RegionAllocator instance dies before the last copy of a new RegionAllocator instance, an exception gets thrown on the death of the RegionAllocator instance and subsequent d'tor call.

On Mon, Jul 18, 2011 at 11:10 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

>
> >________________________________
> >From: David Simcha <dsimcha at gmail.com>
> >
> >I'm working on retrofitting TempAlloc (renamed to RegionAllocator)to fit
> Andrei's proposed allocator interface.  One issue I've run into is, what happens when a scoped allocator is returned from a function?  For example:
> >
> >RegionAllocator fun() {
> >    RegionAllocator alloc;
> >    alloc.malloc(42);
> >
> >    RegionAllocator alloc2;
> >    alloc2.malloc(42);
> >    return alloc2;
> >}
> >
> >Now, alloc has died and alloc2 is still alive, violating LIFO
> requirements.  Since it's virtually impossible to do by mistake, I'm inclined to just make returning a RegionAllocator from a function after another one has been subsequently created undefined behavior.
>
> Can RegionAllocator check on postblit (called during return? not sure) at least in debug mode whether it's valid or not.  I think this might solve the problem.
>
> -Steve
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110718/9302aeaf/attachment.html>

On Fri, 15 Jul 2011 21:47:38 -0400, David Simcha <dsimcha at gmail.com> wrote:

> I'm working on retrofitting TempAlloc (renamed to RegionAllocator)to fit Andrei's proposed allocator interface.  One issue I've run into is, what happens when a scoped allocator is returned from a function?  For example:
>
> RegionAllocator fun() {
>      RegionAllocator alloc;
>      alloc.malloc(42);
>
>      RegionAllocator alloc2;
>      alloc2.malloc(42);
>      return alloc2;
> }
>
> Now, alloc has died and alloc2 is still alive, violating LIFO requirements.  Since it's virtually impossible to do by mistake, I'm inclined to just make returning a RegionAllocator from a function after another one has been subsequently created undefined behavior.
>
> Also, while we're on the subject, does anyone have any serious objections to me keeping frameInit/regionInit and frameFree/regionFree (they've been renamed) public but undocumented?  I need to write a wrapper around this new interface to simulate the old interface and avoid breaking a whole bunch of old code I've written.  I don't see any way to do this without these functions exposed.  Furthermore, they might be useful to people looking to build their own policies on top of RegionAllocator's low-level mechanisms.  Generally I believe that stable low-level features should be exposed to avoid ugly abstraction inversions.

Regarding leaving the low-level features exposed, I don't think they should be undocumented. If they are undocumented, then people won't find them and therefore will create ugly abstraction inversions. You may want to deemphasize them in some way, but they should be documented.