Voler des ressources des clés de std :: map autorisé?

En C ++, est-ce OK de voler des ressources d'une carte dont je n'ai plus besoin par la suite? Plus précisément, supposons que j'ai un std::mapavec des std::stringclés et que je veux en construire un vecteur en volant les ressources des mapclés s en utilisant std::move. Notez qu'un tel accès en écriture aux clés corrompt la structure de données interne (ordre des clés) du mapmais je ne l'utiliserai pas par la suite.

Question : Puis-je le faire sans aucun problème ou cela entraînera-t-il des bogues inattendus, par exemple dans le destructeur du, mapcar j'y ai accédé d'une manière qui std::mapn'était pas destinée?

Voici un exemple de programme:

#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;
}

Il produit la sortie:

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

EDIT: Je voudrais le faire pour tout le contenu d'une grande carte et enregistrer les allocations dynamiques par ce vol de ressources.

Vous faites un comportement indéfini, en utilisant const_castpour modifier une constvariable. Ne fais pas ça. La raison en constest que les cartes sont triées par leurs clés. Ainsi, la modification d'une clé en place rompt l'hypothèse sous-jacente sur laquelle la carte est construite.

Vous ne devez jamais utiliser const_castpour supprimer constd'une variable et modifier cette variable.

Cela étant dit, C ++ 17 a la solution à votre problème: std::mapla extractfonction de:

#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())));
}

Et non using namespace std;. :)

Votre code tente de modifier des constobjets, il a donc un comportement indéfini, comme le souligne correctement la réponse de druckermanly .

Certaines autres réponses ( celles de Phinz et Deuchie ) soutiennent que la clé ne doit pas être stockée en tant constqu'objet car la poignée de nœud résultant de l'extraction de nœuds hors de la carte permet le non- constaccès à la clé. Cette inférence peut sembler plausible au premier abord, mais P0083R3 , l'article qui a introduit les extractfonctionnalités), a une section dédiée sur ce sujet qui invalide cet argument:

Préoccupations

Plusieurs préoccupations ont été exprimées à propos de cette conception. Nous les aborderons ici.

Comportement indéfini

La partie la plus difficile de cette proposition d'un point de vue théorique est le fait que l'élément extrait conserve son type de clé const. Cela évite d'en sortir ou de le changer. Pour résoudre ce problème, nous avons fourni la fonction d'accesseur de clé , qui fournit un accès non constant à la clé dans l'élément détenu par le handle de nœud. Cette fonction nécessite une implémentation "magique" pour s'assurer qu'elle fonctionne correctement en présence des optimisations du compilateur. Une façon de procéder consiste à réunir l'union de pair<const key_type, mapped_type> et pair<key_type, mapped_type>. La conversion entre ceux-ci peut être effectuée en toute sécurité en utilisant une technique similaire à celle utilisée par l' std::launderextraction et la réinsertion.

Nous pensons que cela ne pose aucun problème technique ou philosophique. L' une des raisons pour lesquelles la bibliothèque standard existe est d'écrire du code non portable et magique que le client ne peut pas écrire en C ++ portable (par exemple <atomic>, <typeinfo>, <type_traits>, etc.). Ceci est juste un autre exemple de ce genre. Tout ce qui est exigé des éditeurs de compilateurs pour implémenter cette magie est qu'ils n'exploitent pas un comportement indéfini dans les unions à des fins d'optimisation - et actuellement les compilateurs le promettent déjà (dans la mesure où il est utilisé ici).

Cela impose une restriction au client qui, si ces fonctions sont utilisées, std::pairne peut pas être spécialisé tel qu'il pair<const key_type, mapped_type>a une disposition différente de celle pair<key_type, mapped_type>. Nous pensons que la probabilité que quiconque veuille réellement le faire est effectivement nulle, et dans le libellé formel, nous restreignons toute spécialisation de ces paires.

Notez que la fonction de membre clé est le seul endroit où de telles astuces sont nécessaires et qu'aucune modification des conteneurs ou de la paire n'est requise.

(c'est moi qui souligne)

Je ne pense pas que const_castet la modification conduisent à un comportement indéfini dans ce cas, mais veuillez commenter si cette argumentation est correcte.

Cette réponse affirme que

En d'autres termes, vous obtenez UB si vous modifiez un objet const à l'origine, et sinon non.

Ainsi, la ligne v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));de la question ne mène pas à UB si et seulement si l' stringobjet p.firstn'a pas été créé en tant qu'objet const. Notez maintenant que la référence sur lesextract états

L'extraction d'un nœud invalide les itérateurs de l'élément extrait. Les pointeurs et les références à l'élément extrait restent valides, mais ne peuvent pas être utilisés tant que l'élément appartient à un handle de nœud: ils deviennent utilisables si l'élément est inséré dans un conteneur.

Donc, si je extractle node_handlecorrespondant à p, pcontinue de vivre à son emplacement de stockage. Mais après extraction, je suis autorisé à moveéloigner les ressources de pcomme dans le code de la réponse de druckermanly . Cela signifie que pet donc aussi l' stringobjet p.firstn'a pas été créé comme objet const à l'origine.

Par conséquent, je pense que la modification des mapclés de ne conduit pas à UB et de la réponse de Deuchie , il semble que la structure arborescente maintenant corrompue (maintenant plusieurs mêmes clés de chaîne vides) du mapn'introduise pas de problèmes dans le destructeur. Ainsi, le code de la question devrait fonctionner correctement au moins en C ++ 17 où la extractméthode existe (et l'instruction sur les pointeurs restant valides).

Mise à jour

Je suis maintenant d'avis que cette réponse est erronée. Je ne le supprime pas car il est référencé par d'autres réponses.

EDIT: Cette réponse est fausse. Des commentaires aimables ont souligné les erreurs, mais je ne les supprime pas car elles ont été référencées dans d'autres réponses.

@druckermanly a répondu à votre première question, qui disait que la modification mapforcée des clés rompt l'ordre sur lequel mapla structure de données interne est construite (arbre rouge-noir). Mais il est sûr d'utiliser la extractméthode car elle fait deux choses: déplacer la clé hors de la carte, puis la supprimer, afin qu'elle n'affecte pas du tout l'ordre de la carte.

L'autre question que vous avez posée, à savoir si cela causerait des problèmes lors de la déconstruction, n'est pas un problème. Lorsqu'une carte déconstruit, elle appelle le déconstructeur de chacun de ses éléments (mapped_types, etc.), et la moveméthode garantit qu'il est sûr de déconstruire une classe après qu'elle a été déplacée. Alors ne t'inquiète pas. En bref, c'est l'opération movequi garantit qu'il est sûr de supprimer ou de réaffecter une nouvelle valeur à la classe "déplacée". Plus précisément pour string, la moveméthode peut définir son pointeur char sur nullptr, afin de ne pas supprimer les données réelles qui ont été déplacées lors de l'appel du déconstructeur de la classe d'origine.

Un commentaire m'a rappelé le point que je négligeais, en gros il avait raison mais il y a une chose que je ne suis pas totalement d'accord: ce const_castn'est probablement pas un UB. constest juste une promesse entre le compilateur et nous. les objets notés comme constétant toujours un objet, identiques à ceux qui n'en ont pas const, en termes de types et de représentations sous forme binaire. Lorsque le constest rejeté, il doit se comporter comme s'il s'agissait d'une classe mutable normale. En ce qui concerne move, si vous voulez l'utiliser, vous devez passer un &au lieu d'un const &, donc comme je vois que ce n'est pas un UB, cela rompt simplement la promesse de constet éloigne les données.

J'ai également fait deux expériences, en utilisant MSVC 14.24.28314 et Clang 9.0.0 respectivement, et elles ont donné le même résultat.

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';
}

production:

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

Nous pouvons voir que la chaîne '2' est vide maintenant, mais nous avons évidemment rompu l'ordre de la carte car la chaîne vide devrait être repositionnée à l'avant. Si nous essayons d'insérer, de trouver ou de supprimer certains nœuds spécifiques de la carte, cela peut provoquer une catastrophe.

Quoi qu'il en soit, nous pouvons convenir que ce n'est jamais une bonne idée de manipuler les données internes des classes en contournant leurs interfaces publiques. Le find, insert, les removefonctions et ainsi de suite dépendent de leur exactitude sur la recevabilité de la structure de données interne, et qui est la raison pour laquelle nous devons rester loin de la pensée de jeter un oeil à l' intérieur.