This allows std::is_nothrow_swappable{,_with} to work properly.
This only touches user-facing classes, with the following exceptions:
- map,set: only doc changes (with a drive-by missing semicolon fix),
detail::tree which they derive from already forwards noexcept for swap.
- flat_set: only doc changes for flat_set and a change for
detail::flat_tree, which it derives from to get swap.
- static_vector: while this adds the forwarding, member static_vector::swap
is currently never noexcept, although it could be for noexcept-swappable
and noexcept-move-constructible elements.
- small_vector: there is no free swap, and member swap is never noexcept,
although it could be for noexcept-swappable and noexcept-move-
constructible elements. Swapping small_vectors of exact same type goes
through std::swap, which seems to get noexcept right, and small_vectors
of different sizes use swap for boost::container::vector, which fails
to detect when such swap could be noexcept. This patch doesn't touch
small_vector.
- scoped_allocator: neither member nor free swap are noexcept, although
they should be, and all other constructions/assignments/comparisons too,
as they only forward these operations to underlying allocators, which
are required to not throw exceptions for them. Only static_vector's
static_storage_allocator might throw for these and it shouldn't appear
in scoped_allocator. Unsure of the scope of changes needed or whether it
is even worth it, this patch doesn't touch scoped_allocator.
Previously the iterators of boost::container::deque would assert when
zero was added to them in at least the following situations:
- The iterator was obtained by a call to boost::container::deque::begin
and boost::container::deque::empty returns true
- The iterator was default constructed
This is inconsistent with the way in which the iterators of boost::
container::deque have behaved historically and is also inconsistent
with an understanding of iterators developed by analogy with pointers:
- Adding zero to a null pointer is valid despite the fact the null
pointer cannot be dereferenced
- Adding zero to a pointer that is one past the end yields a pointer
which is still one past the end and thus which has well defined
semantics
Fixed this issue and codified the expected behavior in unit tests.
Most template type parameters 'Allocator' were modified their default type to void since 1.70.0.
These modifications cause has_trivial_destructor_after_move to compile error or yield wrong result.
So, fix them by changing specializations of has_trivial_destructor_after_move.
- Avoid deriving from std::iterator_traits as iterators become too fat.
- Use intrusive's reverse_iterator some std::reverse_iterator-s don't value initialize base.
