On 6/20/2011 11:10 AM, Andrei Alexandrescu wrote:
On 6/20/11 10:01 AM, dsimcha wrote:
== Quote from Andrei Alexandrescu ([email protected])'s
article
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
There are two use cases for implicitly returning TempAlloc-allocated
memory:
1. In a private API.
If we provide an artifact good for private APIs but dangerous for true
modular code, I think this is a weak argument.
Hmm, I'd be fine with leaving out any blatantly obvious way to get
implicit TempAlloc allocation as long as there's a backdoor in place so
that it can be done if you really want to. For example, when allocating
from RegionAllocator, you'd probably want to check that you're
allocating from the last created RegionAllocator anyhow, at least in
debug mode. Therefore, you'd probably want every RegionAllocator to
have a pointer to the previous RegionAllocator. Then you could have a
thread-local RegionAllocator.lastCreated. You could then allocate from
RegionAllocator.lastCreated if you really, really wanted to.
2. I have a few data structures that I may clean up and submit as a
proposal
later (hash table, hash set, AVL tree) whose implementations are
specifically
optimized for TempAlloc. For example, the hash table is provisionally
called
StackHash. I'd really rather write:
auto table = StackHash!(uint, double)(10);
table[666] = 8675309;
rather than:
auto table = StackHash!(uint, double)(10);
table.addElement(666, 8675309, someLongVerboseAllocator);
Couldn't StackHash's constructor accept an allocator as an argument?
Good idea, actually.
