@Araq, you are ahead of me again, and again I'm glad as it means more simplicity, with the thread users somewhat responsible for choosing to use atomic accesses or locks as necessary and tuning the allocation/deallocation process to ensure thread safety.
> There is no reason to take the cost of a lock for every allocation, there are > many ways to avoid that. Interesting, I judged what would be done from your implementation of the shared allocations/deallocations in the current source and it seems you are already thinking of something better. I am already thinking of ways that could be done. > Also, you will be able to setup a thread-local allocator for sections of your > code. The allocator proposal is not part of the "destructor's spec". I didn't know about that. Is the proposal documented somewhere? In trying to implement functional programming concepts in C/C++, I find it to be comparatively slow due to the allocation/deallocation of many small areas of memory as required aren't tuned for that. Perhaps the facilities that will be made available with this new proposal will help one work around that limitation as in allocating larger chunks of memory from the system and then serving out these small allocations from that smaller pooled area; that is how Haskell handles it so much more quickly. Thanks for your patience in walking me through these questions...
