tbd :: concurrent_hash_map의 값으로 std :: unique_ptr을 사용할 때 컴파일 오류가 발생했습니다.

Question

std::unordered_map을 tbb::concurrent_hash_map으로 바꿉니다.

내 원래 코드 :

typedef std::unique_ptr<V> V_ptr; 

std::unordered_map<K, V_ptr> hm; 
V_ptr v (new V); 
K k; 

hm.insert (std::make_pair (k, std::move (v))); 

는 그 소리 3.3와 잘 컴파일합니다. concurrent_hash_map에 unordered_map도 전환 : 오류에

typedef std::unique_ptr<V> V_ptr; 

tbb::concurrent_hash_map<K, V_ptr> hm; 
V_ptr v (new V); 
K k; 

hm.insert (std::make_pair (k, std::move (v))); 

결과 : ...stl_pair.h:105:21: error: call to deleted constructor of 'std::unique_ptr<...

이 연타 3.3의 버그인가? 많은 컨테이너에서 std :: unique_ptrs를 사용할 때 gcc 4.5에 유사한 오류가 있다는 것을 기억합니다. (위의 원래 코드는 예를 들어 gcc 4.5로 컴파일되지 않습니다.) 아니면 concurrent_hash_maps에 대해 뭔가를 놓쳤을까요? 마찬가지로 당신이 std::shared_ptr를 사용하거나 독립 실행 형 벡터에 unique_ptr의를 저장할 수 있습니다 해결

bool insert(const value_type& value); 

:

std::vector<std::unique_ptr<V>> ptrs; 

및 문서 tbb::concurrent_hash_map에 따르면

Answer 1

에만 트리거 const&unique_ptr의 사본을 통해 인수를 취하는 원시 포인터를 concurrent_hash_map에 저장하십시오. 하지만 빈약 한 삭제와 같은 사용 사례에는 허용되지 않을 수 있습니다.

또 다른 가능성은 std::auto_ptr 또는 유사한 것을 사용하는 것입니다. 하지만 그것은 위험합니다. 올바른 사본은 양동이에 도착해야하므로 테스트해야합니다.

Answer 2

아마도 tbb :: concurrent_hash_map에 더 복잡한 삽입 형식을 사용하여이 제한을 해결할 수 있습니다. 다음 코드는 테스트되지 않지만 선험적 나는 그것이 작동하지 왜 아무 이유도 볼 :

typedef std::unique_ptr<V> V_ptr; 

tbb::concurrent_hash_map<K, V_ptr> hm; 
V_ptr v (new V); 
K k; 
{ // this scope controls lifetime of the accessor 
    tbb::concurrent_hash_map::accessor a; 
    hm.insert (a, k);   // insert or find the key 
    a->second = std::move(v); // assign the value 
} 

Answer 3

는 내 질문에 대한 답이 표준을 지원하지 않습니다 TBB는 아직 이동 :: 있다는 점에 동의합니다. 나는 지금 shared_ptr을 고수거야하지만 다음 작품은 주변의 작업을 수행합니다

struct V_ptr : public std::unique_ptr<V> { 

    typedef std::unique_ptr<V> uvptr; 
    using uvptr::uvptr; 
    V_ptr() : std::unique_ptr<V>() {}; 

    V_ptr (const V_ptr& rhs) { 
     this->swap (const_cast<V_ptr&> (rhs)); 
    } 
}; 

나는 그것을 추천 주저 해요하지만.