Std :: shared_ptr <T>: implicit constructor for rvalue pointer for T

Question

I largely support the idea of ​​creating a std::shared_ptr<T> constructor that accepts T * explicitly. it helps save sleepless nights when you look at the cause of a bunch of corruption. Scott Meyers gave a good explanation for this.

---

But ... If I give it an rvalue pointer, is that not so clear? I could do things like:

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

or

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

or a much more painful case from real life

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

---

For me, all these cases are clear enough.

Case (1) is prvalue , I can’t believe that I have two pointers. At least not more than:

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

Case (2) is pretty clear. I agree that after moving something, its value will become undefined. So use it completely on you.

Case (3) is again an rvalue .

---

(Q1) Is it missed by the standard committee?

(Q2) Is there a reason for this?

(Q3) Any possibility for an implicit constructor accepting rvalue to appear in C ++ 14?

Answer 1

The reason even assigning rvalue does not allow the implicit construction of a smart pointer from raw-pointer:

It's not safe.

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

So to the two other parts of your question:

• The committee is not oversight.

and

3. It will not appear in the future C ++ standard (in any case, C ++ 14 is absent, and it did not appear).