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.
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?
I think there are good ways to solve these issues if we start from a
shared view that implicit region allocation has a lot going against it.
In that case, I'm sure we'll find creative solutions. Right now it seems
we're engaging in a pattern of debating disadvantages of passing regions
explicitly, which ignores the disadvantages of having implicit ranges.
Thanks,
Andrei
