4

I am looking to implement a (doubly) linked list which only calls placement new internally, directing all memory to a pool allocated with something like:

char *memPool = new char[4096]; // One-off normal 'new'

Initially I was going to implement my own class which takes a pointer to a (class managing a) pre-allocated memory pool. However I want to be sure first that I can't achieve the same outcome with std::list. In particular, the third section of David Rodríguez's answer to this SO question worries me.

It makes sense that std::list will have to call new and delete on its component nodes, but I want to modify this behaviour so that all the nodes to be allocated with placement new into my custom pool. Therefore my question is:

Is there a way to specify that a placement new std::list such as:

std::list<std::shared_ptr<Cls>> myList = new (pool.getFreeAddr()) list<Cls>;

should also allocate its nodes using a custom allocator, so that everything is stored strictly inside my own memory pool?

(Note: I am aware of the need to use custom allocation/deletion functions with the shared_ptrs if I want them in the custom memory pool too.)

Community
  • 1
  • 1
Ephemera
  • 8,672
  • 8
  • 44
  • 84

1 Answers1

5

You have to:

  • Write a class template MyAllocator that satisfies the Allocator requirements ([allocator.requirements] in the standard).
  • Use a std::list<T, MyAllocator<T> > in place of a std::list<T>.

If you need the type of your list to be specifically std::list<T> (for example because you want to call functions that accept a std::list<T> & and whose interface you can't change), then you're out of luck because the allocator type is part of the container type.

Be careful about the allocator requirements, they're strange. In particular you will need rebind for a list, and it's a bit tricksy.

Furthermore, in C++03 there's no guarantee that allocator instances are respected, only the allocator type, which in effect means that the pointer to the pool you're allocating from needs to be stored with static duration rather than as an instance variable. I think that was changed in C++11, but I might be wrong. It only really matters if you want to use multiple different pools in your program.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • **Writing** `rebind` is trivial. The logic behind it is tricksy. – Pete Becker Mar 20 '13 at 11:06
  • @PeteBecker: good point. But it does mean that for example your allocator can't assume (perhaps as an optimization) that it will only be used with the type `T` you specify to the container. I suppose I needn't have mention the tricksiness -- that fact should be obvious anyway given that it's being used by a linked list, and `rebind` is just the mechanism. – Steve Jessop Mar 20 '13 at 11:16
  • 1
    No, it should be mentioned; it's just that the trickiness is in **what it does**, not in actually writing it. – Pete Becker Mar 20 '13 at 11:19
  • @SteveJessop: In C++11 you can indeed have stateful allocators (and the logic behind does work in case of copy/move of the container). – Matthieu M. Mar 20 '13 at 13:31
  • Looks like I'll be beginning work on a standard-compilant allocator! Happily, refactoring methods (not-)accepting `std::list &` shouldn't be a problem. Thank you for all the information! – Ephemera Mar 21 '13 at 05:07