std :: map의 키에서 리소스를 훔치는 것이 허용됩니까?

C ++에서는 나중에 더 이상 필요하지 않은 맵에서 리소스를 훔치는 것이 괜찮습니까? 더 정확하게 말하면 std::mapwith 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_castconst변수 를 수정하는 데 있습니다. 그렇게하지 마십시오. 그 이유 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이 키에 액세스 할 수 없으므로 키를 객체 로 저장해서는 안된다고 주장합니다 . 이 추론은 처음에는 그럴듯 ​​해 보이지만, P0083R3 은extract 기능 은이 주제에 대해 다음과 같은 논증을 무효화하는 전용 섹션을 가지고 있습니다.

우려 사항

이 디자인에 대해 몇 가지 우려가 제기되었습니다. 우리는 여기서 그것들을 다룰 것입니다.

정의되지 않은 동작

이론적 관점에서이 제안의 가장 어려운 부분은 추출 된 요소가 const 키 유형을 유지한다는 사실입니다. 이것은 밖으로 이동하거나 변경하는 것을 방지합니다. 이를 해결하기 위해 키 접근 자 기능을 제공하여 노드 핸들이 보유한 요소의 키에 대한 비 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가 표시됩니다.

따라서 객체 가 const 객체로 생성되지 않은 v.emplace_back(make_pair(std::move(const_cast<string&>(p.first)),p.second));경우에만 질문 의 줄 이 UB 로 연결되지 않습니다. 이제 상태에 대한 참조는stringp.firstextract

노드를 추출하면 반복자가 추출 된 요소에 대해 무효화됩니다. 추출 된 요소에 대한 포인터와 참조는 유효하지만 노드 핸들이 요소를 소유 한 동안에는 사용할 수 없습니다. 요소가 컨테이너에 삽입되면 사용할 수 있습니다.

나는 그래서 만약 에 해당하는 , 그 저장 위치에 거주하고 있습니다. 그러나 추출 후 druckermanly의 답변 코드에서 와 같이 리소스 를 제거 할 수 있습니다 . 이 수단 따라서 또한 객체가 되었다 하지 원래 const를 대상으로 만들었습니다.extractnode_handleppmoveppstringp.first

따라서, 나는 map키 의 수정이 UB로 이어지지 않으며 Deuchie의 대답 에서 나온 것처럼, 현재 손상된 트리 구조 (현재 여러 개의 동일한 빈 문자열 키)도 map소멸자에 문제를 일으키지 않는 것으로 보입니다 . 따라서 문제의 코드는 적어도 extract메소드가 존재 하는 C ++ 17에서 유효하게 작동해야 합니다 (포인터가 남아있는 포인터에 대한 설명).

최신 정보

나는 지금이 대답이 잘못되었다는 견해를 가지고 있습니다. 다른 답변에서 참조했기 때문에 삭제하지 않습니다.

편집 :이 답변이 잘못되었습니다. 친절한 의견이 실수를 지적했지만 다른 답변에서 참조되었으므로 삭제하지 않습니다.

@druckermanly는 첫 번째 질문에 대답했습니다. 키를 map강제로 변경하면 map내부 데이터 구조가 구축 되는 순서가 손상됩니다 (Red-Black tree). 그러나이 extract방법은 맵에서 키를 옮긴 다음 삭제하여 두 가지 작업을 수행하므로이 방법 을 사용하는 것이 안전합니다 . 따라서 맵 순서에 전혀 영향을 미치지 않습니다.

해체 할 때 문제가 발생하는지 여부에 관한 다른 질문은 문제가 아닙니다. 맵이 해체되면 각 요소 (mapped_types 등)의 해체자를 호출하고 move클래스를 이동 한 후 클래스를 안전하게 해체 할 수 있도록합니다. 걱정하지 마십시오. 간단히 말해서, move"moved"클래스에 새로운 값을 삭제하거나 재 할당하는 것이 안전하도록하는 작업입니다 . 특히 string, move메소드는 char 포인터를로 설정할 수 nullptr있으므로 원래 클래스의 소멸자가 호출되었을 때 이동 한 실제 데이터는 삭제하지 않습니다.

의견은 내가 간과하고있는 요점을 상기시켰다. 기본적으로 그는 옳았지만 내가 완전히 동의하지 않은 한 가지 const_cast가있다. 아마도 UB가 아닐 것이다. const컴파일러와 우리 사이의 약속입니다. 으로 명시 개체 const아직 가진 것과 동일한 목적이다 const바이너리 형태로 해당 유형의 관점에서 표현. const가 캐스트 될 때 마치 일반 가변 클래스 인 것처럼 동작해야합니다. 와 관련하여 move사용하려면 UB &대신 을 전달해야 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등 기능과 내부 데이터 구조의 질서에 자신의 정확성을 의지, 그리고 우리가 내부를 엿의 생각을 멀리해야하는 이유입니다.