allocator

I've been using Howard Hinnant's stack allocator and it works like a charm, but some details of the implementation are a little unclear to me. Why are global operators new and delete used? The allocate() and deallocate() member functions use ::operator new and ::operator delete respectively. Similarly, the member function construct() uses the global placement new. Why not allow for any user-defined global or class-specific overloads? Why is alignment set to hard-coded 16 bytes instead of std::alignment_of<T> ? Why do the constructors and max_size have a throw() exception specification? Isn't

Every allocator class must have an interface similar to the following: template<class T> class allocator { ... template<class Other> struct rebind { typedef allocator<Other> other; }; }; And classes that use allocators do something redundant like this: template<class T, class Alloc = std::allocator<T> > class vector { ... }; But why is this necessary? In other words, couldn't they have just said: template<class T> class allocator { ... }; template<class T, template<class> class Alloc = std::allocator> class vector { ... }; which is both more elegant, less redundant, and (in some similar

I'm new to C++ and I'm using the vector class on my project. I found it quite useful because I can have an array that automatically reallocates whenever it is necessary (ie, if I want to push_back an item and the vector has reached it's maximum capacity, it reallocates itself asking more memory space to the OS), so access to an element of the vector is very quick (it's not like a list, that to reach the "n-th" element I must go through the "n" first elements). I found this question very useful, because their answers explained perfectly how the "memory allocator" works when I want to store my

A different question inspired the following thought: Does std::vector<T> have to move all the elements when it increases its capacity? As far as I understand, the standard behaviour is for the underlying allocator to request an entire chunk of the new size, then move all the old elements over, then destroy the old elements and then deallocate the old memory. This behaviour appears to be the only possible correct solution given the standard allocator interface. But I was wondering, would it make sense to amend the allocator to offer a reallocate(std::size_t) function which would return a pair

If I want to process data in a std::vector with SSE, I need 16 byte alignment. How can I achieve that? Do I need to write my own allocator? Or does the default allocator already align to 16 byte boundaries? C++ standard requires allocation functions ( malloc() and operator new() ) to allocate memory suitably aligned for any standard type. As these functions don't receive the alignment requirement as an argument, on practice it means that the alignment for all allocations is the same and is the alignment of a standard type with the largest alignment requirement, which often is long double and

Is it possible to make std::vector of custom structs allocate aligned memory for further processing with SIMD instructions? If it is possible to do with Allocator , does anyone happen to have such an allocator he could share? Edit: I removed the inheritance of std::allocator as suggested by GManNickG and made the alignment parameter a compile time thing. I recently wrote this piece of code. It's not tested as much as I would like it so go on and report errors. :-) enum class Alignment : size_t { Normal = sizeof(void*), SSE = 16, AVX = 32, }; namespace detail { void* allocate_aligned_memory

What are some really good reasons to ditch std::allocator in favor of a custom solution? Have you run across any situations where it was absolutely necessary for correctness, performance, scalability, etc? Any really clever examples? Custom allocators have always been a feature of the Standard Library that I haven't had much need for. I was just wondering if anyone here on SO could provide some compelling examples to justify their existence. timday As I mention here , I've seen Intel TBB's custom STL allocator significantly improve performance of a multithreaded app simply by changing a single