std::ref_ptr

[masse....@gmail.com]

Hi all,

I recently went to isocpp.org and went across his discussion :

Quick Q: Does using std:: smart pointers mean not using raw pointers?—StackOverflow

After reading most of the posts, especially the one who said that

Even in C++11, raw pointers are still perfectly valid as non-owning references to objects.

something becomes clear in my mind. Men, if using raw pointer is still the recommended things to do in that case, isn't it the sign that something is missing in the standard?
And the fact is that i'm quite sure that yes, something is missing (especially because it's not the first time I read people posting about the use of unique/shared/raw pointers).

Also, I've tried to adress this with a new class called std::ref_ptr.
The idea is to have a pointer wich will not take ownership, but wich can be used for referencing object wich are owned but other pointer (both unique and shared pointers should be supported).
This led me to propose that interface:

template<typename T>
class ref_ptr
{
    ref_ptr(const unique_ptr<T>&);
    ref_ptr(const shared_ptr<T>&); //can be construct from any ownership-enabled pointer. I don't know if those ctors should be made explicit though.
    ref_ptr(const ref_ptr<T>&); //copy constructible
   
    T& operator *() const;
    T* operator ->() const;
    explicit operator bool() const;
    ref_ptr& operator =(const ref_ptr<T>&);
   
    T* get() const;
    //you can add here any method wich can prove to be usefull
};

Advantage over raw pointers:
- can't be used to create new unique/shared_ptr (at least not directly), avoiding potential programming errors.
- need an existing unique/shared_ptr, but can't be construct from raw pointers. This guarantees that the referenced pointer is  to owned by someone and won't be leaked.

Advantage over weak pointers:
- can be used with unique_ptr.
- no need to cast the pointer and construct a new one from it, resulting in better performance. This class will have only one field wich is the pointer itself. This will enable her to perform the same as raw pointers does.

Note :
- Since this class does not deal with ownership, referenced object must outlive the pointer itself. Otherwise, the ref_ptr will become invalid and derefencing it will lead to undefined behaviour.
- I did not add move constructors because I don't think it will any functionnality/benefit over copy constructor.

Uses cases :
- You want to reference an existing object wich you know will still be valid once you will have done with it : use ref_ptr
- You want to reference an existing object, but  you don't know if he will still be valid when you'll need it. 2 possibility :
    --> you want your referenced object to still be valid : use shared_ptr. (having this still valid means that you wanna deal with ownership afterall).
    --> your object can become invalid, you can deal with it (typically, cache systems) : use weak_ptr.

What do you think of this?

PS:
What about std::unique_ptr&?
Another solution for this could be to use reference to std::unique_ptr (or eventually shared one). While I didn't test it, I do believe that a reference to an existing pointer could become invalid at any time when the pointer is moved for example. Can someone confirm me that?

[Zhihao Yuan]

On Mon, Nov 18, 2013 at 6:06 PM, <masse....@gmail.com> wrote:
> Even in C++11, raw pointers are still perfectly valid as non-owning
> references to objects.

> [...]

> Also, I've tried to adress this with a new class called std::ref_ptr.
> The idea is to have a pointer wich will not take ownership, but wich can be
> used for referencing object wich are owned but other pointer (both unique
> and shared pointers should be supported).

I believe this

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3740.pdf

is a better choice.

This paper receives comments like "improve safety, no just T*
replacement of raw pointers" on Chicago.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

[Klaim - Joël Lamotte]

On Tue, Nov 19, 2013 at 12:17 AM, Zhihao Yuan <z...@miator.net> wrote:

This paper receives comments like "improve safety, no just T*
replacement of raw pointers" on Chicago.

I think a good idea would have been to make impossible to delete through this pointer.

This idea have been suggested by someone else on these forums or some other I don't remember,
and I thought it was part of N3740 but apparently not.

[Zhihao Yuan]

On Mon, Nov 18, 2013 at 6:45 PM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:
> I think a good idea would have been to make impossible to delete through
> this pointer.
> This idea have been suggested by someone else on these forums or some other
> I don't remember,
> and I thought it was part of N3740 but apparently not.

??

This is a smart pointer, of course you can't

delete p;

since p is not a pointer.

[Klaim - Joël Lamotte]

On Tue, Nov 19, 2013 at 12:56 AM, Zhihao Yuan <z...@miator.net> wrote:

This is a smart pointer, of course you can't

  delete p;

since p is not a pointer.

Of course! I was being dumb by lack of sleep, sorry.
Did the committee have suggestions on the kind of additional safety that would be useful?

[Zhihao Yuan]

On Mon, Nov 18, 2013 at 7:43 PM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:
> Did the committee have suggestions on the kind of additional safety that
> would be useful?

Restrict the types of pointer comparison (T* _cmp_ V*, where
un-cv T and V should be the same or one is_base_of another).

Restrict the pointer arithmetic (to exempt_ptr<T[]> for example,
which should be able to be used wherever exempt_ptr<T> can
be used).

Explicit convertible to T*, not implicit.

(No poll taken) Disallow creating exempt_ptr from array reference.

[masse....@gmail.com]

To be honest, I don't like the fact that exempt_ptr can be build from raw pointers, because in that case you just don't know if somebody else is already owning the pointer or not.
Also, (but this is mentionned in the proposal), this class isn't aware of any other smart pointers, and consequently does not interact with any of them. I think this must be added.
For the rest, I agree on the fact that safety must be improved (see comment from Zhihao Yuan)