On 6/11/11 11:26 AM, dsimcha wrote:
I've overhauled my TempAlloc proposal based on some of the suggestions
I've received.
Review:
* Mention no safety at disadvantages: deallocating memory may leave
pointers dangling.
* The synopsis should use scope(exit) TempAlloc.frameFree(); as that is
a robust idiom.
* newArray -> "For performance reasons, the returned array is not
initialized." Then call it newUninitializedArray. Make safety the
default and lack thereof the verbose alternative.
* newArray -> "It is not scanned for pointers by the garbage collector
unless GC.addRange is called." I'd agree that malloc() shouldn't do so
because it doesn't know the type, but with newArray you do know the type
so you could automatically call GC.addRange appropriately. If the client
doesn't want that, they can obtain it with extra syntax. Since now you
have two things (uninitialized and noscan) you may want to make them
function parameters instead of part of the function name.
* I'm a bit unsure about free(). People already have the pointer, so
free() should use it as a cheap way to check that they're freeing the
right thing. There should be free(void*), freeLastAllocated(), and
possibly destroyAndFree(T)(T *).
* segmentSlack() -> segmentAvailable().
* stackCat() is a bit surprising. A better way would be something like a
TempAlloc appender that accepts a chain().
* In fact looking at tempArray() just below that's all - it can accept
chain(). No need for stackCat.
* mixin newFrame should be renamed to scopedFrame.
Andrei
