[phobos] Returning Scoped Allocators From Functions

[Robert Jacques]

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.