Custom STL allocator
I am trying to use a custom allocator for STL. I tried the below sample. This prevents assigning a Custom::vector
pointer to std::vector
. Is there any downside or performance issue below.
namespace Custom
{
template <typename _Tp, typename Allocator = CustomAllocator<_Tp> >
class vector : private std::vector<_Tp, Allocator >
{
using std::vector<_Tp, Allocator>::push_back;
};
}
int main(void)
{
Custom::vector<int> v;
v.push_back(1);
}
source to share
Given that there is almost no information on what you are trying to do, where you need to be compatible and where you don’t need to, it’s almost impossible to answer the question.
Assuming the usage declarations are in the visible (i.e. public
) section of the derived type, this is a way to narrow down the interface and set a different allocator. There are various problems here, one of which is that only in context Custom::vector
or a friend
vector can be used as std::vector
, which means that external code cannot convert Custom::vector<T>
to std::vector<T, CustomAllocator<T> >
which can be good or bad. If you need external code to be able to use Custom::vector<T>
as std::vector<T, CA<T>>
(by pointer or reference), you can make inheritance publicly available, or otherwise remove the type and just provide an alias for the type (if the only intent is an allocator for something other than std::allocator<T>
).
Another problem that is present in the C ++ allocator model mostly everywhere is that you no longer have a dictionary type. Two different instances std::vector
(or Custom::vector
, which differ only from the allocator, are unrelated types and cannot be used interchangeably. You cannot write a function that accepts std::vector<T>
and calls it with std::vector<T, CA<T>>
. Or may not be a problem, and can be worked around by polluting templates all over the place ( either working in terms of iterators, or template on an allocator type).
As for this last point, there is a proposal to add a polymorphic allocator to the C ++ standard, and there is an existing implementation in BSL . The compromise pays for additional dynamic distribution for distribution and receives a dictionary type (the code does not require templates,bsl::vector<T>
is the same type, no matter which allocator is used to pull the memory. Regardless of the cost of dynamic dispatch or a big issue for discussion (currently under discussion by the committee). Some initial performance tests seem to indicate that the cost of dynamic dispatch is small with the least performing allocators, but noticeable with faster (fixed buffers, sequential) allocators. this is in context what it means: choosing the right allocator will give you some gain in the C ++ model and a lower gain (constant factor) in the BSL allocator model. A constant ratio is more noticeable when the allocation cost is less. The advantage is thatbsl::vector<T>
is a type of dictionary, the function taking bsl::vector<T>
doesn't care which allocator is used, it just works.
source to share