CODEWITHSUNDEEP
c++c++11vectorstl
user2331977
user2331977

Reputation: 153

STL custom allocator

I am trying to use custom allocator for STL. I tried the below sample. It prevents assigning Custom::vector pointer to std::vector. Is there any disadvantage or performance issue in the below way. 

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);
}

Upvotes: 3

Views: 710

Answers (2)

David Rodr&#237;guez - dribeas
David Rodr&#237;guez - dribeas

Reputation: 208323

Given that there is almost no information as of what you are trying to do, where you need to be compatible and where you need not, it is almost impossible to answer the question.

Assuming that the using declarations are in the visible (i.e. public) section of the derived type, this is a way of narrowing the interface and setting a different allocator. There are different concerns here, one of which is that only within the context of Custom::vector or a friend the vector can be used as a std::vector which means that outer code will not be able to convert Custom::vector<T> into std::vector<T, CustomAllocator<T> > which might be a good or a bad thing. If you need external code to be able to use Custom::vector<T> as a std::vector<T, CA<T>> (by pointer or reference) you could make inheritance public, or otherwise remove the type and just provide a type alias (if the only intention is to default the allocator to something different than std::allocator<T>).

Another issue, which is present in the C++ allocator model basically everywhere, is that you no longer have a vocabulary type. Two different instantiations of std::vector (or Custom::vector that differ only on the allocator are unrelated types and cannot be used interchangeably. You cannot write a function that takes a std::vector<T> and call it with std::vector<T, CA<T>>. Again, this might or might not be an issue, and can be worked around by polluting with templates everywhere (either operate in terms of iterators, or else template on the allocator type).

Regarding 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 trade off is paying for an additional dynamic dispatch per allocation and gaining a vocabulary type (code need not be templated, bsl::vector<T> is the same type regardless of which allocator is used to pull memory. Whether the cost of the dynamic dispatch is small or large is up for discussion (it is currently being discussed by the committee). Some initial performance tests seem to indicate that the cost of dynamic dispatch is smallish with the least performing allocators but noticeable with faster (fixed buffer, sequential) allocators. Take this in context for what it means: choosing the correct allocator will give you some gain in the C++ model, and a smaller gain (constant factor) in the BSL allocator model. The constant factor is more noticeable when the cost of allocation is smaller. The advantage will be that bsl::vector<T> is a vocabulary type, a function taking a bsl::vector<T> does not care about what allocator is in use, it just works.

Upvotes: 1

BeyelerStudios
BeyelerStudios

Reputation: 4283

No.

Performance of allocations is obviously depending on the implementation of CustomAllocator.

Upvotes: 1

Related Questions