Boost logo

Boost :

Subject: Re: [boost] ASIO into the standard
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-11 20:49:45

On 11 Jul 2014 at 21:06, Daniel James wrote:
> >
> > My understanding is that the allocators have to be used for all
> > dynamic allocation. If this is not explicitly worded in the standard,
> > then it should be. Otherwise allocators simply are not as useful with
> > any other interpretation.

I assume by allocators you mean specifically STL allocators?

> I looked this up earlier, as I thought the same. says:
> "Unless otherwise specified, all containers defined in this clause
> obtain memory using an allocator (see"
> Which suggests to me that all allocation is done using the allocator.
> I suppose debug info could be considered something that isn't obtained
> by the container, as it can be external, but I wouldn't have thought
> that for things like buckets.

The standard definitely means an STL allocator, not simply "an

It's not just debug info though. I can think of a number of STL
containers which could use non-STL allocation for internal stuff -
for example, if you create a threadsafe STL container you could
allocate an internal mutex, and it would seem excessive to require
using an externally supplied allocator for that too. Furthermore, a
std::mutex under the hood will almost certainly do some more

You might argue this isn't really allocation of memory. So to
counterexample, what about a STL container of shared memory regions?
Or a STL container of memory mapped files? You'd want the allocator -
given it has 4Kb granularity - to only be used for value types only.
I suppose you could specialise the rebind to avoid this happening,
but we're beginning to chase our tail now.

> says:
> "For the components affected by this subclause that declare an
> allocator_type, objects stored in these
> components shall be constructed using the
> allocator_traits<allocator_type>::construct function and
> destroyed using the allocator_traits<allocator_type>::destroy function
> ( These functions
> are called only for the container´s element type, not for internal
> types used by the container."
> But that's specifying construction, not allocation (btw. I get this
> wrong in unordered, I'll fix it soon).

I have been lazy as it's test code, and implemented a move assignment
like this for an internal item_type due to value_type.first being

    struct item_type
      value_type p;
      size_t hash;
      item_type() : hash(0) { }
      item_type(value_type &&_p, size_t _hash) BOOST_NOEXCEPT :
p(std::move(_p)), hash(_hash) { }
      item_type(item_type &&o) BOOST_NOEXCEPT : p(std::move(o.p)),
hash(o.hash) { }
      item_type &operator=(item_type &&o) BOOST_NOEXCEPT
        new (this) item_type(std::move(o));
        return *this;

Which would normally be unsafe, except everything is noexcept, so I
actually think this is okay except for the fact that the allocator's
construct and destroy aren't being invoked.

> Did I miss anything? I don't claim any expertise here.

Me neither. When do C++ programmers normally implement STL containers
as part of their normal day job? Probably only Stephan. Anyway,
they're a bitch to do correctly and keep performance reasonable.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at