5

Related: Deprecation of std::allocator<void>.

The following description about template parameter Allocator is found for both std::vector and std::list (emphasis mine):

An allocator that is used to acquire/release memory and to construct/destroy the elements in that memory. The type must meet the requirements of Allocator. The behavior is undefined if Allocator::value_type is not the same as T.

The last sentence does not make sense to me. If a specific value_type is required, couldn't it just do an allocator rebind?

Lingxi
  • 14,579
  • 2
  • 37
  • 93
  • I actually couldn't find this requirement in the standard. I am either missing it, or cpp reference here is not correct. – SergeyA May 09 '18 at 04:23
  • 2
    @SergeyA This is given indirectly in the "Allocator-aware container requirements" table in [container.requirements.general], assertion/note for the `allocator_type` expression. – 1201ProgramAlarm May 09 '18 at 04:45
  • @1201ProgramAlarm, oh, general container requirements! Thanks. – SergeyA May 09 '18 at 05:17
  • 1
    Huh, one more crazy thing to add to the list about allocators I suppose. This is particularly weird since `std::list` is almost certainly rebinding to an internal node type – Passer By May 09 '18 at 05:47

1 Answers1

1

The reason is mostly historical—rebinding was more complicated before C++11 added allocator_traits. The Networking TS defines a “proto-allocator” concept ([async.reqmts.proto.allocator]) where rebinding is always applied before any use, so it seems likely that the requirement will be relaxed someday.

Davis Herring
  • 36,443
  • 4
  • 48
  • 76
  • I think the reason is _even more historical_. When STL was written, C++ probably didn't have template template class parameters. Otherwise, we could have the much more logical, `std::vector` or `std::list`, and it would be the class's responsibility to generate the type `std::allocator` (or `std::allocator`). – alfC May 08 '23 at 06:27