Re: STL custom allocator question
On Fri, 8 Aug 2008 17:23:46 -0700, "Kevin" <kevhsu@msn.com> wrote:
All,
I have kind of a newbie question about STL's custom allocators. I'm writing
a game and thus I want to avoid malloc, so naturally I'm inclined to create
a pool custom allocator for std::list. I have implemented one, but when I
instantiate a std::list<mytype_t, mypoolalloc<...>>, the following happens:
1. As expected, my allocator's default constructor is called.
2. STL copy constructs my allocator when creating the head node.
Does the type of the head node derive from the allocator type? If so, it's
doing it to take advantage of the empty base class optimization. It might
seem strange for the list node type to derive in this way instead of the
list itself, but if the allocator type contains virtual functions, anyone
who derives from the allocator can override its virtual functions. If list
derived from allocator, it and types derived from list could
unintentionally override allocator virtual functions, which would be
surprising and bad. Deriving list::node from allocator avoids these
problems, since list can avoid the virtual function issue in the
implementation of its node type.
I'm confused why STL needs to instantiate more than one copy of my
allocator. This is troublesome because I want an instance of my allocator to
contain the chunk pool. But, if this is copy constructed, what am I supposed
to do? Copy the entire pool (that doesn't sound right)?
Or, is the allocator supposed to be an adapter for something external (like
the default heap in the case of the default allocator) and that my design
goal is flawed to begin with?
Each container also has a member function called get_allocator, which
returns a copy of the allocator used in the construction of the container.
In addition, standard containers are allowed to assume all instances of a
given allocator type compare equal and are interchangeable. Therefore, an
allocator is essentially a wrapper type with a standard minimal interface
to a heap, and it should not contain data that would distinguish one object
of a given allocator type from another. IOW, you were on the right track to
figuring this out.
--
Doug Harrison
Visual C++ MVP