TempAlloc: an unusual request

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jun 20 08:10:28 PDT 2011


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.

> 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


More information about the Digitalmars-d mailing list