TempAlloc: an unusual request

[Andrei Alexandrescu]

On 6/19/11 9:48 PM, dsimcha wrote:
> On 6/19/2011 8:00 PM, Andrei Alexandrescu wrote:
>> On 06/19/2011 06:20 PM, dsimcha wrote:
>>> It's ok to allow an object to replace frameInit and frameFree for
>>> conformance to the general allocator interface, but I'd need to keep
>>> frameInit and frameFree around. They're useful for functions that return
>>> pointers to TempAlloc-allocated memory. I don't want to have to pass in
>>> a RegionAllocator object to each of these because it's too verbose. I
>>> want to be able to do:
>>>
>>> void doStuff() {
>>> TempAlloc.frameInit();
>>> scope(exit) TempAlloc.frameFree();
>>>
>>> auto arr = getArray();
>>> }
>>>
>>> uint[] getArray() {
>>> return TempAlloc.newArray!(uint[])(5);
>>> }
>>>
>>>
>>> My other concern is that giving RegionAllocator reference semantics
>>> would, IIUC, require an allocation to allocate a RegionAllocator. Since
>>> TempAlloc is designed to avoid global GC locks/world stopping like the
>>> plauge, this is obviously bad.
>>
>> I was actually glad of that particular outcome...
>
> ??? What outcome?

I was glad that one needs to pass a TempAlloc object down to the 
function, instead of that function silently returning memory allocated 
with TempAlloc. Generally I have a very strong stance against stuff 
that's simultaneously terse, implied, and unsafe. In fact the moment you 
mentioned that the one reason against passing TempAlloc objects down is 
verboseness, I interpreted that as a good argument why it's _good_ to do 
that.

I do agree with your choice of scan flags because your analysis of 
costs, benefits, and onus put on the user is compelling. In this case, 
however, it seems to me that functions that implicitly return stuff on 
the TempAlloc stack are paving the way towards messed-up modules that 
can't be reasoned about modularly.


Thanks,

Andrei