Roubar recursos das chaves do std :: map é permitido?

Em C ++, não há problema em roubar recursos de um mapa que eu não preciso mais mais? Mais precisamente, suponha que eu possua um std::mapcom std::stringchaves e que eu queira construir um vetor roubando os recursos das mapchaves s usando std::move. Observe que esse acesso de gravação às chaves corrompe a estrutura de dados interna (ordenação de chaves) da mapmas não a usarei posteriormente.

Pergunta : Posso fazer isso sem problemas ou isso levará a erros inesperados, por exemplo, no destruidor do, mapporque eu o acessei de uma maneira que std::mapnão foi planejada?

Aqui está um programa de exemplo:

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

Produz a saída:

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

EDIT: Eu gostaria de fazer isso para todo o conteúdo de um mapa grande e salvar alocações dinâmicas por esse roubo de recurso.

Você está fazendo um comportamento indefinido, usando const_castpara modificar uma constvariável. Não faça isso. A razão consté que os mapas são classificados por suas chaves. Portanto, modificar uma chave no local está quebrando a suposição subjacente na qual o mapa é construído.

Você nunca deve usar const_castpara remover constde uma variável e modificar essa variável.

Dito isto, o C ++ 17 tem a solução para o seu problema: std::mapa extractfunção:

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

E não using namespace std;. :)

Seu código tenta modificar constobjetos, por isso tem um comportamento indefinido, como a resposta de druckermanly aponta corretamente.

Algumas outras respostas ( phinz e Deuchie's ) argumentam que a chave não deve ser armazenada como um constobjeto, porque o identificador do nó resultante da extração de nós fora do mapa permite o não constacesso à chave. Essa inferência pode parecer plausível a princípio, mas P0083R3 , o artigo que introduziu as extractfuncionalidades), possui uma seção dedicada sobre esse tópico que invalida esse argumento:

Preocupações

Várias preocupações foram levantadas sobre esse design. Vamos abordá-los aqui.

Comportamento indefinido

A parte mais difícil desta proposta, de uma perspectiva teórica, é o fato de o elemento extraído reter seu tipo de chave const. Isso evita sair dela ou alterá-la. Para resolver isso, fornecemos a função acessador de chave , que fornece acesso não constante à chave no elemento mantido pelo identificador do nó.Esta função requer implementação "mágica" para garantir que funcione corretamente na presença de otimizações do compilador. Uma maneira de fazer isso é com a união de pair<const key_type, mapped_type> e pair<key_type, mapped_type>. A conversão entre eles pode ser realizada com segurança usando uma técnica semelhante à usada std::launderna extração e reinserção.

Não sentimos que isso represente algum problema técnico ou filosófico. Uma das razões pela qual a Biblioteca Padrão existe é escrever código mágico e não portátil que o cliente não pode escrever em C ++ portátil (por exemplo,<atomic> , <typeinfo>, <type_traits>, etc.). Este é apenas outro exemplo. Tudo o que é exigido dos fornecedores de compiladores para implementar essa mágica é que eles não exploram comportamentos indefinidos em uniões para fins de otimização - e atualmente os compiladores já prometem isso (na medida em que isso está sendo aproveitado aqui).

Isso impõe uma restrição ao cliente que, se essas funções forem usadas, std::pairnão pode ser especializada de modo quepair<const key_type, mapped_type> ter um layout diferente pair<key_type, mapped_type>. Sentimos que a probabilidade de alguém realmente querer fazer isso é efetivamente zero e, na redação formal, restringimos qualquer especialização desses pares.

Observe que a chave função de membro é o único local em que esses truques são necessários e que nenhuma alteração nos contêineres ou pares é necessária.

(ênfase minha)

Eu não acho que isso const_caste modificação levem a um comportamento indefinido neste caso, mas por favor, comente se essa argumentação está correta.

Esta resposta afirma que

Em outras palavras, você obtém UB se modificar um objeto const originalmente, e caso contrário não.

Portanto, a linha v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));na pergunta não leva ao UB se e somente se o stringobjeto p.firstnão foi criado como um objeto const. Agora observe que a referência sobreextract estados

A extração de um nó invalida os iteradores para o elemento extraído. Ponteiros e referências ao elemento extraído permanecem válidos, mas não podem ser usados ​​enquanto o elemento pertence a um identificador de nó: eles se tornam utilizáveis ​​se o elemento for inserido em um contêiner.

Portanto, se eu extracto node_handlecorrespondente a p, pcontinuar vivendo no seu local de armazenamento. Mas, após a extração, tenho permissão para moveafastar os recursos do pcódigo da resposta de druckermanly . Isso significa que pe, portanto, também o stringobjeto nãop.first foi criado como objeto const originalmente.

Portanto, acho que a modificação das mapchaves do não leva ao UB e, a partir da resposta de Deuchie , parece que também a estrutura de árvore agora corrompida (agora várias mesmas chaves de cadeia vazias) do mapnão introduz problemas no destruidor. Portanto, o código na pergunta deve funcionar bem, pelo menos no C ++ 17, onde o extractmétodo existe (e a declaração sobre ponteiros permanecendo válidos).

Atualizar

Agora sou da opinião de que esta resposta está errada. Não estou excluindo porque é referenciado por outras respostas.

EDIT: Esta resposta está errada. Comentários gentis apontaram os erros, mas não o excluo porque foi mencionado em outras respostas.

A @druckermanly respondeu à sua primeira pergunta, que dizia que alterar as chaves mappela força quebra a ordem em que mapa estrutura de dados interna é construída (árvore Vermelho-Preto). Mas é seguro usar o extractmétodo porque ele faz duas coisas: mova a chave para fora do mapa e exclua-a, para que não afete a ordem do mapa.

A outra pergunta que você fez, sobre se causaria problemas ao desconstruir, não é um problema. Quando um mapa desconstrói, ele chama o desconstrutor de cada um de seus elementos (mapped_types etc.), e o movemétodo garante que seja seguro desconstruir uma classe depois que ela for movida. Então não se preocupe. Em poucas palavras, é a operação moveque garante que é seguro excluir ou reatribuir algum novo valor à classe "movida". Especificamente para string, o movemétodo pode definir seu ponteiro de char para nullptr, para não excluir os dados reais que foram movidos quando o desconstrutor da classe original foi chamado.

Um comentário me lembrou o ponto que eu estava ignorando, basicamente ele estava certo, mas há uma coisa que eu não concordo totalmente: const_castprovavelmente não é um UB. consté apenas uma promessa entre o compilador e nós. objetos anotados como constainda são um objeto, igual aos que não o são const, em termos de seus tipos e representações na forma binária. Quando o consté descartado, ele deve se comportar como se fosse uma classe mutável normal. No que diz respeito a move, se você quiser usá-lo, precisará passar um em &vez de um const &, então, como vejo que não é um UB, ele simplesmente quebra a promessa deconst e afasta os dados.

Também fiz dois experimentos, usando o MSVC 14.24.28314 e o Clang 9.0.0, respectivamente, e eles produziram o mesmo resultado.

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

resultado:

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

Podemos ver que a string '2' está vazia agora, mas obviamente quebramos a ordem do mapa porque a string vazia deve ser recolocada na frente. Se tentarmos inserir, localizar ou excluir alguns nós específicos do mapa, isso pode causar uma catástrofe.

De qualquer forma, podemos concordar que nunca é uma boa idéia manipular os dados internos de qualquer classe ignorando suas interfaces públicas. A find, insert, removefunções e assim por diante confiar sua correção na ordem da estrutura de dados interna, e essa é a razão por que devemos ficar longe do pensamento de espreitar para dentro.