On Wed, Sep 22, 2010 at 4:49 PM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
Dear Boost Devs,
I am hoping to gain feedback on an ISO C++ standard library proposal I hope to submit. It consists of a rationale (http://mallocv2.wordpress.com/) which shows how growth in RAM capacity is exponentially outgrowing the growth in RAM access speed. The consequences are profound: computer software which has always been written under the assumption of scarcity of RAM capacity will need to be retargeted to assume the scarcity of RAM access speed instead.
I appreciate that Boost is not the C++ standard library, however I have asked this on comp.std.c++ and received no reply at all.
The proposal comes in two parts: (i) The C proposal (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends the classic 1979 malloc API to enable realloc() to speculatively attempt in-place allocation resizing and (ii) the C++ proposal (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends std::allocator<> with batch allocation and deallocation member functions along with a reallocate() member function. These work much as expected and are intended for STL implementations - I have given a sample std::vector<>::reserve() implementation for the Dinkumware STL which attempts an in-place extension before performing a move construction of the vector contents.
I am going to guess that these member functions will be fairly uncontroversial - reallocate() in particular has been in the SGI STL for a while, though in an unhelpful form which is basically a realloc() wrapper. What I think will likely be much more controversial are the new std namespace functions:
template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer New(Args&&... args); template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer NewA(size_t n, Args&&... args); template<class T, class allocator=allocator<T> > void Delete(typename allocator<T>::const_pointer p); template<class T, class allocator=allocator<T> > void DeleteA(typename allocator<T>::const_pointer p);
These parallel global operators new and delete except of course that they are standard functions and take a std::allocator<> type with which they perform the allocation and deallocation. The biggest danger here obviously enough is the chance of collision with any New() or Delete() defined by application code as the overloading and type specialisation problems (thanks to the unhelpful syntax) of operators new and delete are well known. The second biggest danger is the perhaps confusing duplication of functionality, though of course std::New() and std::Delete() are intended as a superset of global operators new and delete.
I would appreciate any feedback, and in case you don't think discussion of this topic is appropriate here I will cross post this email to comp.std.c++. You can reply there instead if you wish.
My thanks in advance for your time and consideration.
Niall Douglas
Have you checked this out? Maybe it can help. http://www.canonware.com/jemalloc/ Regards, Fernando.