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