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
