TempAlloc: an unusual request

[dsimcha]

On 6/20/2011 11:10 AM, Andrei Alexandrescu wrote:
> On 6/20/11 10:01 AM, dsimcha wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'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.