Кража ресурсов из ключей std :: map разрешена?

В C ++ нормально ли красть ресурсы с карты, которая мне больше не нужна? Точнее, предположим, что у меня есть ключи std::mapс std::stringключами, и я хочу создать из него вектор путем кражи ресурсов mapс использованием ключей s 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's extractfunction:

#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 .

В некоторых других ответах ( Финса и Дьючи ) утверждается, что ключ не должен храниться как constобъект, поскольку дескриптор узла, полученный в результате извлечения узлов из карты, допускает отсутствие constдоступа к ключу. На первый взгляд этот вывод может показаться правдоподобным, но P0083R3 , статья, которая представила extractфункциональные возможности), имеет специальный раздел на эту тему, который лишает законной силы этот аргумент:

Обеспокоенность

Несколько проблем были подняты об этой конструкции. Мы обратимся к ним здесь.

Неопределенное поведение

Наиболее сложной частью этого предложения с теоретической точки зрения является тот факт, что извлеченный элемент сохраняет свой тип константного ключа. Это предотвращает выход из него или его изменение. Чтобы решить эту проблему, мы обеспечили ключевую функцию доступа, которая обеспечивает неконстантный доступ к ключу в элементе , принадлежащий ручкой узла. Эта функция требует реализации "магии", чтобы гарантировать ее правильную работу при наличии оптимизаций компилятора. Один из способов сделать это - объединение 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модификация приводит к неопределенному поведению в этом случае, но, пожалуйста, прокомментируйте, верна ли эта аргументация.

Этот ответ утверждает, что

Другими словами, вы получаете UB, если вы изменяете изначально const-объект, а в противном случае - нет.

Таким образом, строка v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));в вопросе не ведет к UB тогда и только тогда, когда stringобъект p.firstне был создан как объект const. Теперь обратите внимание, что ссылка наextract штаты

Извлечение узла делает недействительными итераторы для извлеченного элемента. Указатели и ссылки на извлеченный элемент остаются действительными, но не могут использоваться, пока элемент принадлежит дескриптору узла: они становятся пригодными для использования, если элемент вставлен в контейнер.

Так что, если я , соответствующий , продолжает жить в своем месте хранения. Но после извлечения мне позволено убрать ресурсы, как в коде ответа Дракерманели . Это означает, что и, следовательно, также объект не был изначально создан как объект const.extractnode_handleppmoveppstringp.first

Поэтому, я думаю, что модификация mapключей не приводит к UB, и из ответа Деучи , кажется, что также теперь поврежденная древовидная структура (теперь несколько одинаковых пустых строковых ключей) mapне создает проблем в деструкторе. Таким образом, код в вопросе должен нормально работать, по крайней мере, в C ++ 17, где extractметод существует (и утверждение о том, что указатели остаются действительными, сохраняется).

Обновить

Теперь я считаю, что этот ответ неверен. Я не удаляю его, потому что на него ссылаются другие ответы.

РЕДАКТИРОВАТЬ: Этот ответ неверен. Добрые комментарии указали на ошибки, но я не удаляю их, потому что на них есть ссылки в других ответах.

@druckermanly ответил на ваш первый вопрос, в котором говорилось, что mapпринудительное изменение ключей нарушает порядок, на котором mapстроится внутренняя структура данных (красно-черное дерево). Но использовать extractметод безопасно, потому что он делает две вещи: убирает ключ с карты и затем удаляет его, чтобы он никак не влиял на упорядоченность карты.

Другой вопрос, который вы задали относительно того, не вызовет ли это проблемы при деконструкции, не является проблемой. Когда карта деконструируется, она вызывает деконструктор каждого из своих элементов (mapped_types и т. Д.), И moveметод гарантирует, что безопасно деконструировать класс после его перемещения. Так что не волнуйся. В двух словах, именно эта операция moveгарантирует, что можно безопасно удалить или переназначить какое-то новое значение «перемещенному» классу. Специально для string, moveметод может установить свой указатель на символ nullptr, поэтому он не удаляет фактические данные, которые были перемещены, когда был вызван деконструктор исходного класса.

Комментарий напомнил мне пункт, который я пропустил, в основном он был прав, но есть одна вещь, с которой я не полностью согласен: const_castэто, вероятно, не UB. constэто просто обещание между компилятором и нами. объекты, помеченные как constвсе еще являются объектами, такими же, как те, с которыми они не имеют const, с точки зрения их типов и представлений в двоичной форме. Когда constобъект отбрасывается, он должен вести себя так, как будто это обычный изменяемый класс. Что касается move, если вы хотите использовать его, вы должны передать &вместо 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Функции и так далее полагаться на правильность их упорядоченности внутренней структуры данных, и что является причиной , почему мы должны держаться подальше от мысли о том, заглядывая внутрь.