On Sep 28, 8:30 pm, Dragan Milenkovic <dra...@plusplus.rs> wrote:
> On 09/28/2010 11:03 PM, Howard Hinnant wrote:
>
> > On Sep 28, 2:18 am, Dragan Milenkovic<dra...@plusplus.rs>  wrote:
> > If for example unique_ptr had a dynamic deleter, then it would require
> > an extra allocation in its constructor.  So code that looked like
> > this:
>
> > template<class T>
> > template<class Y>
> > A<T>::A(Y* p)
> > {
> >    unique_ptr<Y>  hold(p);
> >    cntrl_blk_ = new CntrlBlk(p, default_delete<Y>(), allocator<Y>());
> >    hold.release();
> > }
>
> > would instead need to be written with auto_ptr instead of unique_ptr.
> > The code above relies on the fact that the unique_ptr(T*) constructor
> > is noexcept.  The temporary unique_ptr is used just to aggressively
> > establish ownership of 'p', even if the A constructor fails via an
> > exception.
>
> If I'm not mistaken, this may be an example for performance, but
> it's not for exception safety. As a parallel, shared_ptr's ctor
> may throw, but it would will then delete "p". Having unique_ptr
> ctor that is noexcept(false) would still be exception safe in your
> example (yes, the ctor could throw, but other specs would
> remain the same).

<grin> I made the above example by taking my implementation of a
shared_ptr constructor and changing "shared_ptr" to "A". :-)  In other
words, to neatly implement a "unique_ptr" with a dynamic deleter, it
would be helpful to have a unique_ptr with a static deleter to do so.

I point this out not to be argumentative.  I was just amused that we
both went to shared_ptr. :-)

> Too bad that the name "unique_ptr" is already taken, because IMHO
> it would be the most appropriate name for this missing pointer
> (shared vs unique). Boost's "simple_ptr" would be my choice
> for the current "unique_ptr".

I should have pointed out in my previous post that you are not alone.
I believe "dynamic_move_ptr" does exactly what you want:

http://www.coderage.com/move_ptr/libs/move_ptr/doc/index.html

-Howard

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 09/30/2010 09:57 AM, Howard Hinnant wrote:
>
> On Sep 28, 8:30 pm, Dragan Milenkovic<dra...@plusplus.rs>  wrote:

[snip]
>>
>> Too bad that the name "unique_ptr" is already taken, because IMHO
>> it would be the most appropriate name for this missing pointer
>> (shared vs unique). Boost's "simple_ptr" would be my choice
>> for the current "unique_ptr".

Obviously I have forgotten that the name was "scoped_ptr"...

> I should have pointed out in my previous post that you are not alone.
> I believe "dynamic_move_ptr" does exactly what you want:
>
> http://www.coderage.com/move_ptr/libs/move_ptr/doc/index.html

Honestly, I expected more people giving a comment on this topic
(I guess this is where my narcissism comes to play),
either to agree that unique_ptr is not a general pointer
to be used as a return value from a function, or to give
a counter argument to my statements. It would seem that
memory management *is* a very important aspect of C++
and that we should get it right asap.

If I'm missing something obvious here, please point me out.

A few other questions related to memory management
have emerged and I will most likely ask them in
separate threads... but first things first...

--
Dragan

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 15 Sep., 22:09, Dragan Milenkovic <dra...@plusplus.rs> wrote:
> If I'm not mistaken, this is the only discussion about std::make_unique:
>
> http://groups.google.com/group/comp.std.c++/browse_thread/thread/6b8d...
>
> How come no one found any need for make_unique? At least it
> makes the two pointers symmetric... and if someone wanted
> to change shared_ptr to unique_ptr (as I did after seeing
> the thread "returning std::auto_ptr, a question of style"
> in comp.lang.c++.moderated), it could be done without
> additional technical problems.
>
> Certainly, it is more readable to write:
>
> =A0 std::make_unique<Foo>(a, b, c)
>
> than:
>
> =A0 std::unique_ptr<Foo>(new Foo(a, b, c))
>
> ... right?

I don't deny that it is useful, but the addition is clearly
a feature and currently any feature requests have very
little chances of acceptance. No national body has asked
for it (and even if, that would have required some more
reasoning than "it's useful").
I suggest to prepare a proposal for that for the next
standard revision (e.g. for the next TC). Don't start now
with writing, but e.g.in two or three years from now.

HTH & Greetings from Bremen,

Daniel Kr=FCgler

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 15, 1:09=A0pm, Dragan Milenkovic <dra...@plusplus.rs> wrote:
> If I'm not mistaken, this is the only discussion about std::make_unique:
>
> http://groups.google.com/group/comp.std.c++/browse_thread/thread/6b8d...
>
> How come no one found any need for make_unique? At least it
> makes the two pointers symmetric... and if someone wanted
> to change shared_ptr to unique_ptr (as I did after seeing
> the thread "returning std::auto_ptr, a question of style"
> in comp.lang.c++.moderated), it could be done without
> additional technical problems.
>
> Certainly, it is more readable to write:
>
> =A0 std::make_unique<Foo>(a, b, c)
>
> than:
>
> =A0 std::unique_ptr<Foo>(new Foo(a, b, c))
>
> ... right?

To the best of my knowledge, no one such as yourself, ever proposed
it. ;-)  I hope you take that in the spirit it is intended:  to
encourage your participation.

I do recall the issue being briefly discussed, but no one ever
elevated it to an issue or proposal.  One of the nits:  What do you do
about the deleter?

1. Only support default_delete?
  1.A  What about default_delete<T[]>?
2. Create an overload analogous to allocate_shared?

I do think this problem is solvable.  But I point it out to indicate
that things are a little more complex than just slapping in a
make_unique function.  E.g. even if you do (1), and only slap in a
make_unique function, then you have to explain to everyone who will
eventually ask:  How do I use make_unique with a custom deleter?  How
do I use make_unique to create a unique_ptr<T[]>?

-Howard

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 16/09/2010 07:05, Howard Hinnant wrote:
>
> On Sep 15, 1:09=A0pm, Dragan Milenkovic<dra...@plusplus.rs>  wrote:
>>
>> If I'm not mistaken, this is the only discussion about std::make_unique:
>>
>> http://groups.google.com/group/comp.std.c++/browse_thread/thread/6b8d...
>>
>> How come no one found any need for make_unique? At least it
>> makes the two pointers symmetric... and if someone wanted
>> to change shared_ptr to unique_ptr (as I did after seeing
>> the thread "returning std::auto_ptr, a question of style"
>> in comp.lang.c++.moderated), it could be done without
>> additional technical problems.
>>
>> Certainly, it is more readable to write:
>>
>> =A0 std::make_unique<Foo>(a, b, c)
>>
>> than:
>>
>> =A0 std::unique_ptr<Foo>(new Foo(a, b, c))
>>
>> ... right?
>
> To the best of my knowledge, no one such as yourself, ever proposed
> it. ;-)  I hope you take that in the spirit it is intended:  to
> encourage your participation.
>
> I do recall the issue being briefly discussed, but no one ever
> elevated it to an issue or proposal.  One of the nits:  What do you do
> about the deleter?
>
> 1. Only support default_delete?
>   1.A  What about default_delete<T[]>?
> 2. Create an overload analogous to allocate_shared?
>
> I do think this problem is solvable.  But I point it out to indicate
> that things are a little more complex than just slapping in a
> make_unique function.  E.g. even if you do (1), and only slap in a
> make_unique function, then you have to explain to everyone who will
> eventually ask:  How do I use make_unique with a custom deleter?  How
> do I use make_unique to create a unique_ptr<T[]>?
>
> -Howard

Well what do you mean "only slap in a make_unique function" ? :)
Certainly the idea of adding make_unique has merit on its own, and
shooting it down because he didn't suggest adding allocate_unique
seems a bit arbitrary. More seriously, you have a good point. Both
make_unique and allocate_unique would make things more cohesive.

However I don't think your point about deleters is valid: there are no
such factory function for shared_ptr's either! The same goes for T[]:
how does it work with make_shared ?

Frankly I'd really like a make_unique. Nothing special, just a
forwarding function like make_shared. Both are useful for:
a) Don't Repeat Yourself:
std::shared_ptr<T> p { new T(arg1, arg2, ..., argN) };
two maintenance points where T is specified! If you change  the type
of p to std::shared_ptr<U> but not the initializer and if T is
convertible to U...

b) Exception safety:
the classical problem when calling
void func(std::shared_ptr<T> p1, std::shared_ptr<U> p2);
and where
func(std::shared_ptr<T>(new T()), std::shared_ptr<U>(new U()));
seems safe, but is not.

Change all occurrences of shared_ptr to unique_ptr in the above and
I think that's all the case you need in favor of make_unique.
Also I'd even like it if make_unique would just be called make
instead. There'd be a nice parallel between new T(arg1, ..., argN) and
make<T>(arg1, ..., argN). But that's just sugar!

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 09/20/2010 12:54 AM, Luc Danton wrote:
>
> On 16/09/2010 07:05, Howard Hinnant wrote:

[snip]
>>
>> To the best of my knowledge, no one such as yourself, ever proposed
>> it. ;-) I hope you take that in the spirit it is intended: to
>> encourage your participation.
>>
>> I do recall the issue being briefly discussed, but no one ever
>> elevated it to an issue or proposal. One of the nits: What do you do
>> about the deleter?
>>
>> 1. Only support default_delete?
>> 1.A What about default_delete<T[]>?
>> 2. Create an overload analogous to allocate_shared?
>>
>> I do think this problem is solvable. But I point it out to indicate
>> that things are a little more complex than just slapping in a
>> make_unique function. E.g. even if you do (1), and only slap in a
>> make_unique function, then you have to explain to everyone who will
>> eventually ask: How do I use make_unique with a custom deleter? How
>> do I use make_unique to create a unique_ptr<T[]>?
>>
>> -Howard
>
> Well what do you mean "only slap in a make_unique function" ? :)
> Certainly the idea of adding make_unique has merit on its own, and
> shooting it down because he didn't suggest adding allocate_unique
> seems a bit arbitrary. More seriously, you have a good point. Both
> make_unique and allocate_unique would make things more cohesive.
>
> However I don't think your point about deleters is valid: there are no
> such factory function for shared_ptr's either! The same goes for T[]:
> how does it work with make_shared ?
>
> Frankly I'd really like a make_unique. Nothing special, just a
> forwarding function like make_shared. Both are useful for:
> a) Don't Repeat Yourself:
> std::shared_ptr<T> p { new T(arg1, arg2, ..., argN) };
> two maintenance points where T is specified! If you change the type
> of p to std::shared_ptr<U> but not the initializer and if T is
> convertible to U...
>
> b) Exception safety:
> the classical problem when calling
> void func(std::shared_ptr<T> p1, std::shared_ptr<U> p2);
> and where
> func(std::shared_ptr<T>(new T()), std::shared_ptr<U>(new U()));
> seems safe, but is not.
>
> Change all occurrences of shared_ptr to unique_ptr in the above and
> I think that's all the case you need in favor of make_unique.
> Also I'd even like it if make_unique would just be called make
> instead. There'd be a nice parallel between new T(arg1, ..., argN) and
> make<T>(arg1, ..., argN). But that's just sugar!

Thanks for the support. First, I have to admit that so far
I have only used shared_ptr (although it was ever since 5-6 years ago).
Recently, in the discussion I mentioned ("returning std::auto_ptr,
a question of style") a statement was made that one is better
returning std::unique_ptr which can then be moved to std::shared_ptr
if the one who invoked the function desires a shared ownership.
I agree with this statement, and this has inspired me to review
my memory management.

[slightly_offtopic]
Additionally, I was even more recently involved in a bit
of MSVC environment specifics and memory management across
the DLL boundary, but I say this just to clarify the context,
nothing else.
[/slightly_offtopic]

I always believed that shared_ptr and unique_ptr had almost
identical interfaces, among others - both featuring deleters.
Imagine my surprise two days ago when I found out this:

template <typename T, typename D> unique_ptr;
vs.
template <typename T> shared_ptr;

Hopefully, I have successfully setup a context for my following
question -- Why is "typename D" there?

My quick guess would be that this makes unique_ptr much more
lightweight than shared_ptr (which has to wrap the deleter
in a polymorphic wrapper in order to implement the support).
But is there a better reason than this one? Why would it
be so bad if unique_ptr got a bit more weight? Its usage
excludes copying and assigning, IMHO it would not be
such a performance hit, certainly less operations are
done on a unique_ptr compared to a shared_ptr.

I'll explain why I would like my unique_ptr more like shared_ptr.
Again back to the "returning std::unique_ptr from a function"
One can NOT always put:
  virtual std::unique_ptr<Foo> make_foo() const = 0;
because this limits the deleter to std::default_deleter,
which severely limits the implementations.
OTOH, shared_ptr doesn't imply this limitation.

MSVC environment encourages memory management such as:
Foo * CreateFoo();
void DeleteFoo(Foo * foo);

And I would like to use it this way:

std::shared_ptr<Foo> ProperCreateFoo() {
   return
       std::shared_ptr<Foo>
           (CreateFoo(), DeleteFoo);
}

... but with unique_ptr it becomes...

std::unique_ptr<Foo, void (*)(Foo*)> ProperCreateFoo() {
   return
       std::unique_ptr<Foo, void (*)(Foo*)>
           (CreateFoo(), DeleteFoo);

... which IMHO brings an implementation detail (the used
deleter) to the interface (type declaration here), and may also
lead to other problems later in the design later.

Sorry for writing a long essay. Looking forward to feedback...

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 28, 2:18 am, Dragan Milenkovic <dra...@plusplus.rs> wrote:

> I always believed that shared_ptr and unique_ptr had almost
> identical interfaces, among others - both featuring deleters.
> Imagine my surprise two days ago when I found out this:
>
> template <typename T, typename D> unique_ptr;
> vs.
> template <typename T> shared_ptr;
>
> Hopefully, I have successfully setup a context for my following
> question -- Why is "typename D" there?
>
> My quick guess would be that this makes unique_ptr much more
> lightweight than shared_ptr (which has to wrap the deleter
> in a polymorphic wrapper in order to implement the support).
> But is there a better reason than this one? Why would it
> be so bad if unique_ptr got a bit more weight? Its usage
> excludes copying and assigning, IMHO it would not be
> such a performance hit, certainly less operations are
> done on a unique_ptr compared to a shared_ptr.

Exception safety and performance are the main reasons.  Every design
decision made for unique_ptr was predicated on not adding overhead
over auto_ptr or a built-in pointer (unless that overhead was
associated with functionality explicitly requested).  Had this not
been the driving goal, then auto_ptr could not have been deprecated.
If for example unique_ptr had a dynamic deleter, then it would require
an extra allocation in its constructor.  So code that looked like
this:

template <class T>
template <class Y>
A<T>::A(Y* p)
{
   unique_ptr<Y> hold(p);
   cntrl_blk_ = new CntrlBlk(p, default_delete<Y>(), allocator<Y>());
   hold.release();
}

would instead need to be written with auto_ptr instead of unique_ptr.
The code above relies on the fact that the unique_ptr(T*) constructor
is noexcept.  The temporary unique_ptr is used just to aggressively
establish ownership of 'p', even if the A constructor fails via an
exception.

I find that I code the above pattern /very/ often, more so because I
can use a custom deleter.  The custom deleter often calls
allocator::deallocate, or closes a file, or locks or unlocks a mutex.
It is so much easier to write exception safe code knowing that the
unique_ptr constructor isn't going to throw, and knowing that it is
virtually cost-free in terms of performance.

> I'll explain why I would like my unique_ptr more like shared_ptr.
> Again back to the "returning std::unique_ptr from a function"
> One can NOT always put:
>   virtual std::unique_ptr<Foo> make_foo() const = 0;
> because this limits the deleter to std::default_deleter,
> which severely limits the implementations.
> OTOH, shared_ptr doesn't imply this limitation.
>
> MSVC environment encourages memory management such as:
> Foo * CreateFoo();
> void DeleteFoo(Foo * foo);
>
> And I would like to use it this way:
>
> std::shared_ptr<Foo> ProperCreateFoo() {
>    return
>        std::shared_ptr<Foo>
>            (CreateFoo(), DeleteFoo);
>
> }
>
> ... but with unique_ptr it becomes...
>
> std::unique_ptr<Foo, void (*)(Foo*)> ProperCreateFoo() {
>    return
>        std::unique_ptr<Foo, void (*)(Foo*)>
>            (CreateFoo(), DeleteFoo);
>
> ... which IMHO brings an implementation detail (the used
> deleter) to the interface (type declaration here), and may also
> lead to other problems later in the design later.

A unique-ownership-with-dynamic-deleter smart pointer is a valid and
valuable abstraction.  There is absolutely nothing wrong with it and
it has valuable use cases such as the one you outline above.  But it
is not unique_ptr, and its existence can not replace unique_ptr.  Such
a smart pointer can be built out of either shared_ptr or unique_ptr.
Your use of unique_ptr above with a function pointer deleter is a good
approximation to a dynamic deleter which could be encapsulated within
a wrapper smart pointer class.  Such a smart pointer might even find a
place in a future C++ standard, but its time is not now.

-Howard

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 09/28/2010 11:03 PM, Howard Hinnant wrote:

> On Sep 28, 2:18 am, Dragan Milenkovic<dra...@plusplus.rs>  wrote:
>
[snip]

> My quick guess would be that this makes unique_ptr much more
>> lightweight than shared_ptr (which has to wrap the deleter
>> in a polymorphic wrapper in order to implement the support).
>>
> [snip]

>
> Exception safety and performance are the main reasons.  Every design
> decision made for unique_ptr was predicated on not adding overhead
> over auto_ptr or a built-in pointer (unless that overhead was
> associated with functionality explicitly requested).  Had this not
> been the driving goal, then auto_ptr could not have been deprecated.
> If for example unique_ptr had a dynamic deleter, then it would require
> an extra allocation in its constructor.  So code that looked like
> this:
>
> template<class T>
> template<class Y>
> A<T>::A(Y* p)
> {
>    unique_ptr<Y>  hold(p);
>    cntrl_blk_ = new CntrlBlk(p, default_delete<Y>(), allocator<Y>());
>    hold.release();
> }
>
> would instead need to be written with auto_ptr instead of unique_ptr.
> The code above relies on the fact that the unique_ptr(T*) constructor
> is noexcept.  The temporary unique_ptr is used just to aggressively
> establish ownership of 'p', even if the A constructor fails via an
> exception.
>

If I'm not mistaken, this may be an example for performance, but
it's not for exception safety. As a parallel, shared_ptr's ctor
may throw, but it would will then delete "p". Having unique_ptr
ctor that is noexcept(false) would still be exception safe in your
example (yes, the ctor could throw, but other specs would
remain the same).

Having said that, I don't mind having a lightweight pointer
whose ctor doesn't throw...

[snip]

> Again back to the "returning std::unique_ptr from a function"
>> One can NOT always put:
>>   virtual std::unique_ptr<Foo>  make_foo() const = 0;
>> because this limits the deleter to std::default_deleter,
>> which severely limits the implementations.
>> OTOH, shared_ptr doesn't imply this limitation.
>>
> [snip]

> A unique-ownership-with-dynamic-deleter smart pointer is a valid and
> valuable abstraction.  There is absolutely nothing wrong with it and
> it has valuable use cases such as the one you outline above.  But it
> is not unique_ptr, and its existence can not replace unique_ptr.  Such
> a smart pointer can be built out of either shared_ptr or unique_ptr.
> Your use of unique_ptr above with a function pointer deleter is a good
> approximation to a dynamic deleter which could be encapsulated within
> a wrapper smart pointer class.  Such a smart pointer might even find a
> place in a future C++ standard, but its time is not now.
>

I appreciate the thorough explanation. I'm glad that it doesn't
contradict any of my conclusions about the existing pointers,
one of those being that there is one pointer missing.
May I conclude that using a unique_ptr as a return value from
a function is not a general solution for all designs?
This goes against the conclusion I have drawn from the thread
I keep referencing...

Too bad that the name "unique_ptr" is already taken, because IMHO
it would be the most appropriate name for this missing pointer
(shared vs unique). Boost's "simple_ptr" would be my choice
for the current "unique_ptr".

--
Dragan

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

If I'm not mistaken, this is the only discussion about std::make_unique:

http://groups.google.com/group/comp.std.c++/browse_thread/thread/6b8df2550961b2e2

How come no one found any need for make_unique? At least it
makes the two pointers symmetric... and if someone wanted
to change shared_ptr to unique_ptr (as I did after seeing
the thread "returning std::auto_ptr, a question of style"
in comp.lang.c++.moderated), it could be done without
additional technical problems.

Certainly, it is more readable to write:

  std::make_unique<Foo>(a, b, c)

than:

  std::unique_ptr<Foo>(new Foo(a, b, c))

... right?

--
Dragan

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sep 15, 3:09=A0pm, Dragan Milenkovic <dra...@plusplus.rs> wrote:
> If I'm not mistaken, this is the only discussion about std::make_unique:
>
> http://groups.google.com/group/comp.std.c++/browse_thread/thread/6b8d...

Good point... also, make_shared isn't in the index of library names in
N3126.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]