Slight extension to shared_ptr to convert to unique_ptr

[DeadMG]

One of the things that annoys me about the Standard ownership classes is that you have to choose which one you want ahead of time. Sometimes this is fine, but sometimes it's rather annoying.

So I propose std::unique_ptr<T, std::function<void(T*)>>.

Principally, I believe this already functions for most cases. The primary issue is that shared_ptr cannot convert. I suggest that shared_ptr have an explicit conversion (operator?) to unique_ptr<T, implementation-defined>, where the deleter manages the reference count. This way, unique_ptrs with type-erased or templated deleters can represent any ownership scheme.

[Daniel Krügler]

2012/12/19 DeadMG <wolfei...@gmail.com>:

> One of the things that annoys me about the Standard ownership classes is
> that you have to choose which one you want ahead of time. Sometimes this is
> fine, but sometimes it's rather annoying.
>
> So I propose std::unique_ptr<T, std::function<void(T*)>>.

Why is the binding to std::function<void(T*)> so very important? You can already
instantiate this template now:

#include <functional>
#include <memory>

template<class T>
using my_ptr = std::unique_ptr<T, std::function<void(T*)>>;

struct S {};

int main() {
my_ptr<int> pi(new int(12));
my_ptr<S> ps(new S{});

}

> Principally, I believe this already functions for most cases. The primary
> issue is that shared_ptr cannot convert. I suggest that shared_ptr have an
> explicit conversion (operator?) to unique_ptr<T, implementation-defined>,
> where the deleter manages the reference count. This way, unique_ptrs with
> type-erased or templated deleters can represent any ownership scheme.

This would violate the contract of shared_ptr and unique_ptr. unique_ptr has the
invariant, that only one pointer owns the resource. You cannot
guarantee this (in general)
after with a shared_ptr as source, which may have multiple copies.

Please take a look at

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031

If you have answers to the questions asked then I suggest to create
a proposal paper. Ensure that you reference LWG issue 1031 and expect
that people will ask critical questions in regard to invariants and
implement-ability.

- Daniel

[DeadMG]

A unique_ptr constructed from a shared_ptr does not own the resource that the shared_ptr owns. It owns one strong reference to that resource. It, essentially, acts like a shared_ptr<T> but cannot be copied. The implementation-defined deleter object acts like the destructor of a shared_ptr.

How does one handle custom deleters given to the shared_ptr constructor?

The deleter holds a strong reference to the control block the source shared_ptr is using, which holds the shared_ptr's deleter, along with the reference count and whatnot.

What is the interface for such a conversion when the shared_ptr does not have unique ownership? Throw an exception? Create a null unique_ptr? Undefined behavior?

The same as for any other time.

[Peter Sommerlad]

why would you want to prohibit copying a shared_ptr? unique_ptr can not serve that role IMHO

> --
>
>
>

--
Prof. Peter Sommerlad

Institut für Software: Bessere Software - Einfach, Schneller!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.s...@hsr.ch

[Mateusz Loskot]

On 19 December 2012 11:46, DeadMG <wolfei...@gmail.com> wrote:
> A unique_ptr constructed from a shared_ptr does not own the resource that
> the shared_ptr owns. It owns one strong reference to that resource. It,
> essentially, acts like a shared_ptr<T> but cannot be copied.

This sounds like a significant change to the unique_ptr semantic,
which retains sole ownership of object.
IMO, you simply ask for a different type of smart pointer
a noncopyable std::strong_ptr ?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[DeadMG]

It retains sole ownership of an object- the strong reference. 

[Sebastian Gesemann]

On Wed, Dec 19, 2012 at 11:41 AM, DeadMG wrote:
> One of the things that annoys me about the Standard ownership classes is
> that you have to choose which one you want ahead of time.

It's part of the design, so, of course you have to choose this in advance.

> So I propose std::unique_ptr<T, std::function<void(T*)>>.
>
> Principally, I believe this already functions for most cases. The primary
> issue is that shared_ptr cannot convert. I suggest that shared_ptr have an
> explicit conversion (operator?) to unique_ptr<T, implementation-defined>,
> where the deleter manages the reference count. This way, unique_ptrs with
> type-erased or templated deleters can represent any ownership scheme.

This does not seem to be a compelling case. It's not clear what
semantics it is supposed to have and how it can be implemented. What
do you mean by "where the deleter manages the reference count"? In
what situations do you want to allow such conversion? Are there any
constraints and/or preconditions to this conversion? Are you proposing
this conversion to always "work" or only in case the source
shared_ptr<T> is an rvalue and invoking its unique() member function
yields true?

[DeadMG]

 In what situations do you want to allow such conversion?

All of them. The conversion behaves like a copy of the source shared_ptr in every respect, and is just as valid. It can be implemented fairly easily. In fact, it's more than possible to implement shared_ptr on top of unique_ptr.

What do you mean by "where the deleter manages the reference count"

The implementation-defined deleter in the result deals with decrementing the reference count, and possibly deleting the object- that is, it acts like ~shared_ptr(), effectively. 

[Sebastian Gesemann]

What would be the point of doing that? The resulting unique_ptr object
would not be the unique owner. But unique ownership is kind of the
point of having a unique_ptr. Sorry, but this does not make any sense
to me. For some reason you want to have a unique_ptr that acts as a
shared_ptr for no apparent benefit.

[DeadMG]

It is the unique owner of one strong reference. And the principle benefit is that it would now be possible to write a function that takes any kind of pointer at run-time. The others are more easily achieved with custom deleters, but shared_ptr needs some special support.

[Sebastian Gesemann]

On Thu, Dec 20, 2012 at 2:04 PM, DeadMG <wolfei...@gmail.com> wrote:
> It is the unique owner of one strong reference.

A shared_ptr is also "the unique owner of one strong reference". I
don't understand why you want to write "unique_ptr" and use it like a
shared_ptr.

> And the principle benefit is
> that it would now be possible to write a function that takes any kind of
> pointer at run-time.

How? To do what with it?

> The others are more easily achieved with custom
> deleters, but shared_ptr needs some special support.

Not convinced at all. And unless that changes somehow, you won't hear
from me on this topic again.

[DeadMG]

A shared_ptr is also "the unique owner of one strong reference".

Which is why it's simple to implement and also simple conceptually. In fact, shared_ptr could be expressed as simply a special case of unique_ptr. Why does it surprise you that I might want to deal with any unique_ptr, regardless of if it is a special case or not?

How? To do what with it? 

Using unique_ptr<T, function<void(T*)>>, so that you don't have to force an ownership scheme on to your interface's client, something which is both very common and currently, quite irritating. Is not being more generic and more flexible enough for you?

[Ville Voutilainen]

On 20 December 2012 15:39, DeadMG <wolfei...@gmail.com> wrote:
> Using unique_ptr<T, function<void(T*)>>, so that you don't have to force an
> ownership scheme on to your interface's client, something which is both very
> common and currently, quite irritating. Is not being more generic and more
> flexible enough for you?

unique_ptr attempts to force a _stricter_ ownership scheme than
shared_ptr. Again,
write a custom deleter and use that with unique_ptr, I fail to see why
we should standardize
such a custom deleter.

[Olaf van der Spek]

Op woensdag 19 december 2012 12:01:02 UTC+1 schreef Daniel Krügler het volgende:

Please take a look at

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031

If you have answers to the questions asked then I suggest to create
a proposal paper. Ensure that you reference LWG issue 1031 and expect
that people will ask critical questions in regard to invariants and
implement-ability.

 I think this request is somewhat different. The request is not to transfer ownership to unique_ptr, but for unique_ptr to hold a (one) reference to the shared object.

struct C

{

  C(P&& p) : p_(p) { }

private:

  P p_;

}

What should P be here? If it's unique_ptr, I can't store a shared_ptr. If it's a shared_ptr, I can't store a raw or unique_ptr without overhead (control block alloc).

Just using shared_ptr as much as possible avoids the issue but might not always be possible.

[Ville Voutilainen]

On 20 December 2012 16:03, Olaf van der Spek <olafv...@gmail.com> wrote:
> I think this request is somewhat different. The request is not to transfer
> ownership to unique_ptr, but for unique_ptr to hold a (one) reference to the
> shared object.
> struct C
> {
> C(P&& p) : p_(p) { }
> private:
> P p_;
> }
> What should P be here? If it's unique_ptr, I can't store a shared_ptr. If
> it's a shared_ptr, I can't store a raw or unique_ptr without overhead
> (control block alloc).
> Just using shared_ptr as much as possible avoids the issue but might not
> always be possible.

If you make that

C(P&& p) : p_(move(p)) {}

it should work when p_ is a shared_ptr, since you can move-construct a
shared_ptr
and you can also move-construct a shared_ptr from a unique_ptr.

[DeadMG]

It could work, but forces reference counting, which is not ideal if I only need unique semantics on the result.

[Ville Voutilainen]

On 20 December 2012 16:22, DeadMG <wolfei...@gmail.com> wrote:
> It could work, but forces reference counting, which is not ideal if I only
> need unique semantics on the result.

For such optimized custom cases, you can specialize that C, or create a wrapper
that can take shared_ptr or unique_ptr. The case for supporting shared->unique
conversions in the standard doesn't thus far seem very convincing.

[Olaf van der Spek]

On Thu, Dec 20, 2012 at 3:24 PM, Ville Voutilainen
<ville.vo...@gmail.com> wrote:
> For such optimized custom cases,

What happened to "You don't pay for what you don't use?"
This isn't some rare use case, in fact I think it's quite a common use case.


--
Olaf

[DeadMG]

Creating the wrapper would require the above functionality. Also, specializing C won't always work- for example, if I intend to ship precompiled code.

[Daniel Krügler]

2012/12/20 Olaf van der Spek <olafv...@gmail.com>:

> Op woensdag 19 december 2012 12:01:02 UTC+1 schreef Daniel Krügler het
> volgende:
>
>> Please take a look at
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#1031
>>
>> If you have answers to the questions asked then I suggest to create
>> a proposal paper. Ensure that you reference LWG issue 1031 and expect
>> that people will ask critical questions in regard to invariants and
>> implement-ability.
>
>
> I think this request is somewhat different. The request is not to transfer
> ownership to unique_ptr, but for unique_ptr to hold a (one) reference to the
> shared object.

Yes, the requester has made his point clear after I presented the
issue and the question,
but this is not the only possible interpretation (see my quoted
issue). To the contrary
I would assume that any implicit conversion from shared_ptr to unique_ptr would
*transfer* ownership, because that is the main intention of unique_ptr
and the reason
for naming it that way.

It is just the fact that the generic deleter support and the generic
pointer support of
unique_ptr can be used to support very different models. Nonetheless I
consider such
models as very special. There is no reason that the standard library
should support
such special scenarios *directly*.

> struct C
> {
> C(P&& p) : p_(p) { }
> private:
> P p_;
> }
>
> What should P be here? If it's unique_ptr, I can't store a shared_ptr. If
> it's a shared_ptr, I can't store a raw or unique_ptr without overhead
> (control block alloc).
>
> Just using shared_ptr as much as possible avoids the issue but might not
> always be possible.

I don't find the example compelling enough to standardize a conversion from
any shared_ptr to unique_ptr. It would give a false impression what
the responsibility
of the pointee would be.

The current design already allows anyone to implement the request very easily,
like so:

#include <memory>

template<class T>

struct pseudo_deleter {
typedef std::shared_ptr<T> pointer;
void operator()(pointer) const {}
};

template<class T>
using funny_ptr = std::unique_ptr<T, pseudo_deleter<T>>;

int main()
{
std::shared_ptr<int> pi(new int(12));
funny_ptr<int> pf(pi);
}

I don't think that this is worth standardizing this: The request would have the
effect that code that was unintentionally written would compile and would
possible do different things as expected. This is different, if a user
explicitly
provides std::unique_ptr<T, pseudo_deleter<T>> to those who are interested
in such conversion (Add to the list a factory function template, if
you prefer). If this
conversion support result in funny programs they can complain to the inventor
of funny_ptr.

- Daniel

[Ville Voutilainen]

Then by all means substantiate your claims - if it's common, you have
better grounds
for standardizing it. And, if you have a
unique_ptr-wrapping-a-shared-block, you are
paying for the shared_ptr cost, there's no optimization in having that
unique_ptr there.

[DeadMG]

Particularly, recently I was using the Clang API. They have a nasty habit of using something similar to this, except without any security or safety whatsoever- passing booleans to indicate ownership. In addition, if Clang owns an object that you have created, then it will always delete that object, making it impossible to use any custom allocators. And there is no way in hell that they could convert half their codebase to be templated on pointer types.

 There is no reason that the standard library 
should support 
such special scenarios *directly*. 

The user-defined equivalents are not as efficient as a Standardised variant. Your class showing an alteration of the unique_pointer using the deleter typedef is not possible to use as a run-time abstraction. If a template would be sufficient, then I could simply template on the pointer type directly.

[Daniel Krügler]

2012/12/20 DeadMG <wolfei...@gmail.com>:

> Particularly, recently I was using the Clang API. They have a nasty habit of
> using something similar to this, except without any security or safety
> whatsoever- passing booleans to indicate ownership. In addition, if Clang
> owns an object that you have created, then it will always delete that
> object, making it impossible to use any custom allocators. And there is no
> way in hell that they could convert half their codebase to be templated on
> pointer types.

I don't know the Clang API, so I cannot properly respond whether it
makes sense to compare it with an std::shared_ptr to std::unique_ptr
conversion.

>> There is no reason that the standard library
>> should support
>> such special scenarios *directly*.
>
>
> The user-defined equivalents are not as efficient as a Standardised variant.

Sorry, I cannot accept this argument alone, because this can be
brought for *anything* that is not yet part of the library.

> Your class showing an alteration of the unique_pointer using the deleter
> typedef is not possible to use as a run-time abstraction. If a template
> would be sufficient, then I could simply template on the pointer type
> directly.

Your initial request was quite nebulous to me (and it still is),
therefore I brought the example of an existing issue. I constructed
funny_ptr from my *understanding* what you want to have supported. Now
you claim that I'm not properly modeling your intention. I can accept
that, so I'm giving this here my recommendation to you:

Please write up a concrete proposal that makes *clear* what you think
should be supported and what you *think* you want to impose on
implementations to realize that and what your think what kind of
problems they solve. Remember that your *idea* somewhere in your mind
alone will not be sufficient to ensure that any future implementation
would realize what you *thought* they should. Wording needs to be
added that realizes this. A reference implementation is not required
but I think would be helpful, because at least I have not finally
understood your full *requirements* are.

Given these requirements I would still like to see what impact this
request would have on possible std::unique_ptr implementations.

- Daniel

[Sebastian Gesemann]

On Thu, Dec 20, 2012 at 2:39 PM, DeadMG <wolfei...@gmail.com> wrote:
> Sebastian wrote:

>> DeadMG wrote:
>>> And the principle benefit is that it would now be possible
>>> to write a function that takes any kind of pointer at run-time.

>> How? To do what with it?
> Using unique_ptr<T, function<void(T*)>>, so that you don't have to force an
> ownership scheme on to your interface's client, something which is both very
> common and currently, quite irritating. Is not being more generic and more
> flexible enough for you?

I have two problems with this:

(1) If this thing is more general and allowed shared ownership as well
it should not have the name "unique_ptr". The meaning of
unique_ptr<T,...> is "unique owner of a T" and not "unique owner of
something else that is somehow related to some T whose ownership is
possibly shared".

(2) I fail to imagine use cases for a more general
"uncertain-ownership-at-compile-time-and-move-only" smart pointer.
What are these use cases?

[Paul Smith]

A general note: I think you managed to confuse pretty much everyone

(including me) with your exposition. When you make a proposal, don't

assume that everyone knows what you're talking about - be more elaborate.

A use case, preferably a small piece of code that demonstrates the issue and

your proposed solution, is always a good idea.

That being said, I think I managed to understand what you're aiming at (I might be wrong, though.)

You're basically looking for a type-erased smart-pointer. Why you decided

to use 'unique_ptr' for this task is beyond me. A 'unique_ptr' is just what it's

name says: the unique owner of *the object it points to* - not of a reference

to the object or whatnot. It's just not what it's for.

You're looking for some kind of 'any_ptr<T>': something that can be used to store

a dumb pointer, but also a 'shared_ptr' or (perhaps) anything that behaves like a pointer.

I doubt that it can be safely used to store a 'unique_ptr', though, as the uniqueness

of the ownership is mandated by the non-copyability of 'unique_ptr', which is lost

when the type is erased.

I find the general usefulness of this somewhat questionable. Once again, I suggest that

you present a real use case. You might also be interested in the recently-accepted

Boost.TypeErasure library, that can be used to implement something like this, although it's

scope is much broader (and might be more expensive than a specilizaed class in

this case. I'm not familiar enough with the library to tell.)

--

Paul Smith

 

[Nevin Liber]

On 20 December 2012 08:42, DeadMG <wolfei...@gmail.com> wrote:

 There is no reason that the standard library 
should support 
such special scenarios *directly*. 

The user-defined equivalents are not as efficient as a Standardised variant.

Please substantiate this claim.  Are you saying that your proposal requires a magic type that has special compiler support?

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[Sebastian Gesemann]

On Thu, Dec 20, 2012 at 2:39 PM, DeadMG wrote:
> > [...]

> Using unique_ptr<T, function<void(T*)>>, so that you don't have to force an
> ownership scheme on to your interface's client, something which is both very
> common and currently, quite irritating. Is not being more generic and more
> flexible enough for you?

Two issues:

(1) I think your idea to (mis)use "unique_ptr" for something that is
actually more like an "uncertain_ptr" (uncertain with respect to
ownership at compile-time) is a bad idea. unique_ptr<T,...> means
"unique ownership of a T" and not "unique ownership of something else
entirely that is somhow linked to a T object could possibly be
shared".

(2) I have trouble imagining use cases for this. That's why I asked
about how you would use such a thing.

[Sebastian Gesemann]

On Thu, Dec 20, 2012 at 4:24 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
> On 20 December 2012 08:42, DeadMG <wolfei...@gmail.com> wrote:
>>>
>>> There is no reason that the standard library
>>> should support
>>> such special scenarios *directly*.
>>
>> The user-defined equivalents are not as efficient as a Standardised
>> variant.
>
> Please substantiate this claim. Are you saying that your proposal requires
> a magic type that has special compiler support?

I can actually answer this. The inner workings of a shared_ptr (how it
manages the reference counts and deleters) are implementation details.
An "uncertain_ptr" (*) could quite possibly exploit this knowledge and
avoid extra book keeping and/or allocations that would otherwise be
necessary.

(* uncertain ownerchip at compile-time with keep-alive functionality
when converted from unique_ptr or shared_ptr)

[Fernando Cacciola]

On Thu, Dec 20, 2012 at 12:39 PM, Sebastian Gesemann
<s.ges...@gmail.com> wrote:
> On Thu, Dec 20, 2012 at 4:24 PM, Nevin Liber <ne...@eviloverlord.com> wrote:
>> On 20 December 2012 08:42, DeadMG <wolfei...@gmail.com> wrote:
>>>>
>>>> There is no reason that the standard library
>>>> should support
>>>> such special scenarios *directly*.
>>>
>>> The user-defined equivalents are not as efficient as a Standardised
>>> variant.
>>
>> Please substantiate this claim. Are you saying that your proposal requires
>> a magic type that has special compiler support?
>
> I can actually answer this. The inner workings of a shared_ptr (how it
> manages the reference counts and deleters) are implementation details.
> An "uncertain_ptr" (*) could quite possibly exploit this knowledge and
> avoid extra book keeping and/or allocations that would otherwise be
> necessary.
>

Like pretty much everyone else here I have no idea what the requester
wants and even less why he choose unique_ptr for that. But like you I
did grasp that it has something to do with recycling and perhaps
adapting the mechanism that shared_ptr uses to control ownership.

So, it's seems that he wants some sort of most basic smart_ptr, one
that would serve as a basis for the others.

It reminds me of the good old policy-based smart pointers from
Alexandrescu. But then I recall when that form of design did not make
it into Boost (and I was among the ones that preferred the simpler
shared_ptr).

Being able to change the ownership strategy as you copy or move
objects along might be a reasonable requirement. Specially if the
change is in the right direction (like from uniquely owned to shared)

Unfortunately, that's a far as the vague idea goes in my head. I can't
think of anything more concrete, so, I'm left with the feeling that he
is on to something valid, but can't quite get it.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

[Ville Voutilainen]

On 20 December 2012 13:39, DeadMG <wolfei...@gmail.com> wrote:
> It retains sole ownership of an object- the strong reference.

So, what you want is a freedom to get _some_ kind of a unique_ptr from
a shared_ptr, in order
to be able to cope with unfortunate design decisions in module X, to
express different semantics
in module Y. So far, in general, I support such wishes.

But now there's a snag: I assume you need unique_ptr<T,
strongref_deleter>? If you can control
that module Y uses such a type, wouldn't you also be able to control
that it just uses a shared_ptr?
In other words, while the idea of expressing different semantics is
sometimes sound, I fail to
see what problem we're practically solving here, and why you couldn't
just use shared_ptr in
module Y. Is it intended to just prevent copying (but allow moving) of
the handle-to-T in module Y?
Can't you just write a custom deleter that is constructible from a
shared_ptr, and use a unique_ptr
with such a deleter?

[Ville Voutilainen]

Creating the wrapper does not require standard support for direct conversion
from shared_ptr to unique_ptr.

[Mateusz Loskot]

On 20 December 2012 11:39, DeadMG <wolfei...@gmail.com> wrote:
> It retains sole ownership of an object- the strong reference.

I refer to resource ownership and the statement from your post:

"does not own the resource that the shared_ptr owns"

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[Tony V E]

FWIW, this is my interpretation as well.

I do see some usefulness. At least for a function that just uses the
pointer and doesn't keep it beyond the function call. Should that
function instead take the raw pointer? (Maybe, but I think many
people are trying to avoid raw pointers completely, and the conversion
to raw pointer is ugly.) Or does that function need to be templatized
just so it can use whatever pointer type the client has? Neither
option seems great. Converting to a type-erased pointer makes some
sense.

Now _keeping_ that any_ptr<T> around inside a struct becomes scary.
Or copying it. How does that work with a unique_ptr? Or do the
copy-semantics need to be runtime as well? Call ptr.clone() which
does move for unique_ptr but ref++ for shared_ptr????

Tony

[Marshall Clow]

On Dec 20, 2012, at 7:47 AM, Tony V E <tvan...@gmail.com> wrote:

> FWIW, this is my interpretation as well.
>
> I do see some usefulness. At least for a function that just uses the
> pointer and doesn't keep it beyond the function call. Should that
> function instead take the raw pointer? (Maybe, but I think many
> people are trying to avoid raw pointers completely, and the conversion
> to raw pointer is ugly.)

I call that "a reference" unless it is optional, in which case a pointer is the best choice.

-- Marshall

Marshall Clow Idio Software <mailto:mclow...@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki