std::unique_ptr is it really drop in replacement for raw pointer?|

[atch...@gmail.com]

Is std::unique_ptr supposed to be drop in replacement for raw pointers? That is I mean 100% compatibility if I change raw pointers in my code to std::unique?
Thank you

[Andrey Semashev]

Of course not. Even disregarding the interface differences, unique_ptr
has different semantics from a raw pointer in general.

[Daniel Krügler]

If that compatibility guarantee would hold, what would be the
advantage of std::unique_ptr?

I think you need to specify more concretely, what you mean by "100%
compatibility". In particular, std::unique_ptr is "just" a plain
standard library component and there do not exist specific core
language rules that consider std::unique_ptr as special type. There
exist a number of ways how to observe the difference, one example
would be the (failing) attempt to take advantage of covariant return
types using std::unique_ptr.

- Daniel

[atch...@gmail.com]

The advantage that springs to mind is guaranteed no memory leaks.

[atch...@gmail.com]

Andrew, could you explain shortly what are the differences in semantics from raw ptr?
Thank you.

[Andrey Semashev]

> On Sunday, 6 March 2016 13:25:50 UTC+1, Andrey Semashev wrote:
>

> On 2016-03-06 15:13, atch...@gmail.com <javascript:> wrote:
> > Is std::unique_ptr supposed to be drop in replacement for raw
> pointers?
> > That is I mean 100% compatibility if I change raw pointers in my
> code to
> > std::unique?
>
> Of course not. Even disregarding the interface differences, unique_ptr
> has different semantics from a raw pointer in general.

On 2016-03-06 15:55, atch...@gmail.com wrote:
> Andrew, could you explain shortly what are the differences in semantics
> from raw ptr?

The most apparent difference is the ownership model. unique_ptr implies
that the pointer owns the resource and is responsible for freeing it.
Raw pointers do not own the resource.

Next, unique_ptr does not support pointer arithmetics, aside from the
indexing operator for array specializations. Raw pointers do support it
and because of that can be used as iterators.

So, unique_ptr can and should replace raw pointers in one specific use
case - when you use raw pointers to keep reference to an allocated
resource for later deallocation. It won't be a drop-in replacement
because of interface differences. That's not the only application of raw
pointers, and unique_ptr won't be appropriate in the other cases.

[atch...@gmail.com]

Thank you Andrew, appreciated.
Best Regards

[Nicol Bolas]

On Sunday, March 6, 2016 at 7:48:12 AM UTC-5, atch...@gmail.com wrote:

The advantage that springs to mind is guaranteed no memory leaks.

But it guarantees no such thing. If two objects own unique_ptrs to each other, then you have a circular reference which will never be destroyed.

[atch...@gmail.com]

Hi Nicol, good hearing from ye, me ol' china!
What do you do then in situation as you've just described?
Thank you

[Tony V E]

0. std-discussion‎ really isn't a place for tutorial or reference questions

1. You need to avoid circular references on your own

2. Not yet mentioned by anyone

- With unique_ptr‎, only one ptr can/should be pointing to an object at any time‎ (thus the name 'unique')

- the object was allocated

- you stop calling delete directly (if that wasn't obvious)

So in situations where the object is allocated with new, and there is NEVER more than one pointer pointing to it at the same time, then you can replace those pointers with unique_ptr, and remove your call to delete. 

Now you can, with extra care and syntax, break the above rules, but typically you don't. 

Sent from my BlackBerry portable Babbage Device

From: atch...@gmail.com Sent: Sunday, March 6, 2016 8:44 AM To: ISO C++ Standard - Discussion Reply To: std-dis...@isocpp.org Cc: atch...@gmail.com Subject: Re: [std-discussion] std::unique_ptr is it really drop in replacement for raw pointer?|

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

[daniele...@gmail.com]

The new observer_ptr could be considered a drop in.....

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3840.pdf

unique_ptr is designed so that there can be only one owner. For something else to point to the object that the unique_ptr points to, you would have to transfer ownership using std::move. 

[FrankHB1989]

在 2016年3月7日星期一 UTC+8下午2:27:12，daniele...@gmail.com写道：

This is not "drop in replacement" for several reasons:

• You need explicit construction or a helper like "make_observer" to initialize a value of instance of "observer_ptr". Replacing the type of builtin pointers will generally fail.
• The semantics only covers a quite narrow subset of cases. For example, it now does not support pointer arithmetic, which is not handled well by std::unique_ptr, either. This lost random iterator semantics may need some other new interface as replacement.
• The core language relies on pointer types. Replacing the rules of new-expressions is difficult. Replacing the use in standard library is impossible if C compatibility is remained. In such cases, raw pointers will still be disabled to express the specific ownership clearly.

To be serious, raw pointer types (if any) should be a derived type in a well-designed language. Specifically, object pointer can be a sum type, like template<typename T> using __pointer = __variant<__unique_ptr<T>, __observer_ptr<T>, __raw_storage_random_access_iterator<T>, __uintptr_with_some_check_t /* implementation-defined or conditionally supported, __some_other_mess<AddressSpace, T>*/, ...>. This is so complicated that certainly not fit for the core language. (And ABI issues are already completely ignored here.) C/C++'s pointer is just a dirty hack of real need, but it just "works". Thus I don't think there can be such a ready-to-use "drop in replacement" in the near future.