19

As said by cppreference.com,

Maps are usually implemented as red-black trees.

So moving a std::map is just moving the pointer to the root node + other information such as size. Why is std::map's move constructor not marked as noexcept?

Kelvin Zhang
  • 892
  • 6
  • 23
  • 2
    Possible duplicate of [Why aren't container move assignment operators noexcept?](https://stackoverflow.com/questions/12332772/why-arent-container-move-assignment-operators-noexcept) – Gupta Jul 31 '19 at 22:23
  • There is one overload that takes an allocator argument. That presumably needs to allocate new nodes and move-construct the contents, so allocation could fail. This doesn't explain the other overload though, since the allocator itself should be move constructible. – Useless Jul 31 '19 at 22:25
  • 3
    Not a duplicate of [Why aren't container move assignment operators noexcept?](https://stackoverflow.com/q/12332772/576911) because a move constructor is not the same thing as a move assignment operator. Furthermore the answer for these two _different_ special members is _different_. – Howard Hinnant Jul 31 '19 at 23:21

1 Answers1

21

It is because I couldn't talk all of the implementors into a resource-less state that the map could be put into. For example an implementation needs to have an end-node to point to, even in the default-constructed state. Implementations are allowed, but not required, to put that end-node on the heap.

A moved-from map must be in a valid state. I.e. a moved-from map must have an end node to point to when end() gets called. Before the move construction, there exists one end node in the map that you're about to move from. After the move construction there must exist two end nodes: one in the new map and one in the moved-from `map.

If the end node goes on the heap, that means that the move constructor either doesn't transfer ownership of the end node, and thus has to allocate a new end node for the new `map. Or does transfer the end node, but then has to allocate a new one to leave in the moved-from source.

If the end node is instead embedded within the map data structure itself, then it never need be allocated on the heap. It is automatically "allocated on the stack" as the map gets constructed.

Implementations are allowed to make the map move constructor noexcept if they want to, they just aren't required to.

Here is a survey of the noexcept-state of the default constructor, move constructor and move assignment operator of the containers among the implementations that I took several years ago. This survey assumes std::allocator for each container. I just spot checked it for map and the results haven't changed.

If you would like to run this survey yourself, here is the code:

#include "type_name.h"
#include <iostream>
#include <type_traits>

#include <deque>
#include <forward_list>
#include <list>
#include <vector>
#include <string>
#include <map>
#include <set>
#include <unordered_map>
#include <unordered_set>

template <class C>
void
report()
{
    using namespace std;
    const auto name = type_name<C>();
    if (is_nothrow_default_constructible<C>::value)
        std::cout << name << " is noexcept default constructible\n";
    else
        std::cout << name << " is NOT noexcept default constructible\n";
    if (is_nothrow_move_constructible<C>::value)
        std::cout << name << " is noexcept move constructible\n";
    else
        std::cout << name << " is NOT noexcept move constructible\n";
    if (is_nothrow_move_assignable<C>::value)
        std::cout << name << " is noexcept move assignable\n\n";
    else
        std::cout << name << " is NOT noexcept move assignable\n\n";
}

int
main()
{
    using namespace std;
    report<deque<int>>();
    report<forward_list<int>>();
    report<list<int>>();
    report<vector<int>>();
    report<string>();
    report<map<int, int>>();
    report<set<int>>();
    report<unordered_map<int, int>>();
    report<unordered_set<int>>();
}

where "type_name.h" comes from this answer.

Howard Hinnant
  • 192,948
  • 49
  • 425
  • 554
  • looking at the survey, it seems like MSVC's `std::map` implementation isn't noexcept movable. I'm curious what is special about MSVC's implementation that `std::map` can't be noexcept moved? – Kelvin Zhang Aug 01 '19 at 02:22
  • For the move constructor, they put their end node on the heap, thus they always have to allocate an end node during move construction. – Howard Hinnant Aug 01 '19 at 13:33
  • If the end node is on the heap, why can't it copy the pointer to end node during move? – Kelvin Zhang Aug 01 '19 at 15:18
  • [A moved-from `map` must be in a valid state.](https://stackoverflow.com/a/7028318/576911) I.e. a moved-from `map` must have an end node to point to when `end()` gets called. Before the move construction, there exists one end node. After the move construction there must exist two end nodes. If the design is that end nodes go on the heap, then a new one must be allocated. If the design is that end nodes are embedded within the `map`, then the end node "allocation" is "on the stack". – Howard Hinnant Aug 01 '19 at 15:34
  • Thx. That's the answer I'm looking for. Would you edit your answer to include this comment? – Kelvin Zhang Aug 02 '19 at 03:18
  • Done. If that's still not right, just let me know how I can improve it, thanks. – Howard Hinnant Aug 02 '19 at 13:48
  • So this means I cannot create a noexcept move constructor for any class that contains map instances. Correct? – Tohnmeister Aug 31 '20 at 13:15
  • You could make your move constructor conditionally `noexcept`, conditioned on if `map` is `is_nothrow_move_constructible`. This would create a `noexcept` move constructor on 2 out of 3 major implementations. – Howard Hinnant Aug 31 '20 at 13:23