允许从std :: map的键中窃取资源吗？

在C ++中，可以从以后不再需要的映射中窃取资源了吗？更准确地说，假设我有一个std::mapwith std::string键，并且我想通过使用窃取maps键的资源来构造一个向量std::move。请注意，对键的这种写访问会破坏的内部数据结构（键的顺序），map但此后我将不再使用它。

问题：我可以这样做没有任何问题吗？还是会导致意外的错误（例如，map由于我std::map以非预期的方式访问它）而导致了析构函数的错误？

这是一个示例程序：

#include<map>
#include<string>
#include<vector>
#include<iostream>
using namespace std;
int main(int argc, char *argv[])
{
    std::vector<std::pair<std::string,double>> v;
    { // new scope to make clear that m is not needed 
      // after the resources were stolen
        std::map<std::string,double> m;
        m["aLongString"]=1.0;
        m["anotherLongString"]=2.0;
        //
        // now steal resources
        for (auto &p : m) {
            // according to my IDE, p has type 
            // std::pair<const class std::__cxx11::basic_string<char>, double>&
            cout<<"key before stealing: "<<p.first<<endl;
            v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));
            cout<<"key after stealing: "<<p.first<<endl;
        }
    }
    // now use v
    return 0;
}

它产生输出：

key before stealing: aLongString
key after stealing: 
key before stealing: anotherLongString
key after stealing: 

编辑：我想对一张大地图的整个内容执行此操作，并通过此资源窃取来保存动态分配。

您正在执行未定义的行为，const_cast用于修改const变量。不要那样做 这const是因为地图是按其键排序的。因此，就地修改键会破坏构建地图的基础假设。

您永远不要使用从变量中const_cast删除并修改该变量。const

话虽这么说，C ++ 17有你的问题的解决方案：std::map的extract功能：

#include <map>
#include <string>
#include <vector>
#include <utility>

int main() {
  std::vector<std::pair<std::string, double>> v;
  std::map<std::string, double> m{{"aLongString", 1.0},
                                  {"anotherLongString", 2.0}};

  auto extracted_value = m.extract("aLongString");
  v.emplace_back(std::make_pair(std::move(extracted_value.key()),
                                std::move(extracted_value.mapped())));

  extracted_value = m.extract("anotherLongString");
  v.emplace_back(std::make_pair(std::move(extracted_value.key()),
                                std::move(extracted_value.mapped())));
}

而且不要using namespace std;。:)

您的代码尝试修改const对象，因此它具有未定义的行为，正如druckermanly的答案正确指出的那样。

其他一些答案（phinz和Deuchie的观点）则认为，不得将密钥存储为const对象，因为从映射中提取节点而导致的节点句柄允许不const访问密钥。最初，这种推断似乎是合理的，但是引入功能的论文P0083R3extract对此主题有专门的章节，使该论点无效：

顾虑

有人对此设计提出了一些担忧。我们将在这里解决。

未定义的行为

从理论角度来看，该建议最困难的部分是提取的元素保留其const键类型的事实。这样可以防止移出或更改它。为了解决这个问题，我们提供了密钥访问器功能，该功能提供了对由节点句柄持有的元素中的密钥的非常量访问。此功能需要实现“魔术”，以确保在存在编译器优化的情况下其正确运行。一种实现方法是使用pair<const key_type, mapped_type> 和的并集pair<key_type, mapped_type>。这些之间的转换可以使用类似于std::launder提取和重新插入所使用的技术安全地实现 。

我们认为这不构成任何技术或哲学问题。一的标准库中存在的原因是写非便携式和神奇代码，客户端无法在可移植的C ++编写（例如<atomic>，<typeinfo>，<type_traits>等等）。这只是另一个这样的例子。编译器供应商要实现此魔力，所需要做的全部就是，他们不为了优化目的而利用联合中未定义的行为-并且当前，编译器已经承诺了这一点（在此方面加以利用）。

这确实对客户端施加了限制，即如果使用了这些功能，std::pair则无法对其进行专门化，以使其pair<const key_type, mapped_type>布局与有所不同 pair<key_type, mapped_type>。我们认为任何人实际想要执行此操作的可能性实际上为零，并且在正式措辞中，我们限制了这些对的任何专门化。

请注意，关键成员函数是唯一需要这种技巧的地方，并且不需要更改容器或容器对。

（强调我的）

我不认为const_cast在这种情况下，修改会导致未定义的行为，但请评论此论点是否正确。

这个答案声称

换句话说，如果您修改了原始的const对象，您将获得UB，否则，您将得到UB。

因此v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));，仅当未将string对象p.first创建为const对象时，问题中的行才不会导致UB 。现在请注意有关extract状态的 参考

提取节点会使迭代器对提取的元素无效。指向提取的元素的指针和引用仍然有效，但是在元素由节点句柄拥有时不能使用：如果将元素插入容器中，则它们变得可用。

因此，如果我extract与node_handle相对应p，则p继续住在其存储位置。但是提取后，我被允许像德鲁克曼利的答案代码中那样浪费move资源。这意味着该对象也因此最初未被创建为const对象。ppstringp.first

因此，我认为对map'键的修改不会导致UB，并且从Deuchie的回答来看，似乎现在损坏的树结构（现在有多个相同的空字符串键）map也不会在析构函数中引入问题。因此，问题中的代码至少应在extract存在该方法的C ++ 17中正常工作（并且有关指针的声明仍然有效）。

更新资料

我现在认为这个答案是错误的。我没有删除它，因为其他答案引用了它。

编辑：这个答案是错误的。友善的评论指出了这些错误，但由于它已在其他答案中引用，因此我没有将其删除。

@druckermanly回答了您的第一个问题，即map用力更改键会破坏map构建内部数据结构（红黑树）的有序性。但是使用该extract方法是安全的，因为它有两件事：将密钥移出地图，然后再将其删除，因此它根本不会影响地图的有序性。

您提出的关于在解构时是否会引起麻烦的另一个问题不是问题。映射解构时，它将调用其每个元素的解构器（mapped_types等），并且该move方法确保在移动类后可以安全地解构一个类。所以不用担心 简而言之，正是这种操作move确保了可以安全地删除某些新值或将新值重新分配给“移动”类。专门针对string，该move方法可以将其char指针设置为nullptr，因此它不会删除在调用原始类的解构函数时移动的实际数据。

一条评论让我想起了我所忽略的观点，基本上他是对的，但有一点我并不完全同意：const_cast可能不是UB。const只是我们和编译器之间的承诺。就其类型和二进制形式的表示而言，标记为const的对象仍然与不使用的对象相同const。当const被抛弃，它应该表现为，如果它是一个正常的可变类。关于move，如果要使用它，则必须传递a &而不是a const &，因此，如我所见，它不是UB，它只是违反了诺言const并移走了数据。

我还进行了两个实验，分别使用MSVC 14.24.28314和Clang 9.0.0，它们产生了相同的结果。

map<string, int> m;
m.insert({ "test", 2 });
m.insert({ "this should be behind the 'test' string.", 3 });
m.insert({ "and this should be in front of the 'test' string.", 1 });
string let_me_USE_IT = std::move(const_cast<string&>(m.find("test")->first));
cout << let_me_USE_IT << '\n';
for (auto const& i : m) {
    cout << i.first << ' ' << i.second << '\n';
}

输出：

test
and this should be in front of the 'test' string. 1
 2
this should be behind the 'test' string. 3

我们可以看到字符串'2'现在为空，但是显然我们已经破坏了地图的有序性，因为应该将空字符串重新放置在前面。如果我们尝试插入，查找或删除地图的某些特定节点，则可能会导致灾难。

无论如何，我们可能会同意，绕过它们的公共接口来操纵任何类的内部数据绝不是一个好主意。的find，insert，remove功能等依赖于内部数据结构的有序性的正确性，这就是为什么我们应该偷看里面的思想望而却步的原因。