std :: shared_ptr <T>: niejawny konstruktor dla wskaźnika rvalue na T

Question

W dużym stopniu popieram pomysł utworzenia konstruktora std::shared_ptr<T>, który akceptuje wyraźną akceptację T *. pomaga oszczędzić bezsenną noc, gdy patrzysz na przyczynę korupcji sterty. Scott Meyers dał dobre wyjaśnienie tego.

---

Ale ... Jeśli dam mu wskaźnik rvalue nie jest to jednoznaczne? Mogę robić takie rzeczy jak:

/// (1) 
std::shared_ptr<T> t = new T; 

lub

/// (2) 
T * giveaway = new T; 
std::shared_ptr<T> t = std::move(giveaway); 

lub znacznie bardziej bolesna sprawa z realnym życiu

/// (3) 
void foo(std::shared_ptr<T> t); 
/// ... 
foo(new T); 

---

Jak dla mnie, wszystkie te przypadki są dość wyraźne .

Przypadek (1) to prvalue, nie mogę się wykręcić mając dwa wskaźniki. Przynajmniej nie więcej niż za pomocą:

std::shared_ptr<T> t{new T}; 

Przypadek (2) jest dość wyraźny. Uzgodniono, że po przeniesieniu czegoś jego wartość staje się niezdefiniowana. Więc używanie go jest całkowicie przy tobie.

Przypadek (3) to ponownie rvalue.

---

(Q1) To jest to przeoczyć standardowym komisji?

(Q2) Czy istnieje ku temu powód?

(Q3) Czy istnieje szansa, aby niejawny konstruktor zaakceptował pojawienie się w C++ 14 numeru rvalue?

Answer 1

Jest powód, nawet dając rvalue nie pozwala niejawny budowę inteligentnych wskaźnik od surowego wskaźnik:

To nie jest bezpieczne.

void foo(std::shared_ptr<T> t); 
char buffer[42]; 
foo(buffer+7); // buffer+7 is a rvalue, and would implicitly convert! 

Zatem, do pozostałych dwóch częściach pytanie:

1. To nie przeoczenie przez komisję.

I

3. To nie pojawią się w przyszłości C++ - Standardowy (Zresztą, C++ 14 jest obecnie i to nie pojawiają).