I note that the draft (n2369) has shared_ptr constructors which take
auto_ptr. Since auto_ptr has been deprecated, shouldn't these be
changed to take unique_ptr?

Yechezkel Mett

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

Yechezkel Mett ha scritto:
> I note that the draft (n2369) has shared_ptr constructors which take
> auto_ptr. Since auto_ptr has been deprecated, shouldn't these be
> changed to take unique_ptr?
>

Even if auto_ptr has been deprecated, I don't think the constructor with
the auto_ptr should be removed. However, I agree that adding a new
constructor that takes a unique_ptr is definetely a good idea,
especially because such constructor should take the unique_ptr deleter
into consideration. For example, if u is a unique pointer, then

  shared_ptr p(u);

should be equivalent to:

  shared_ptr p(u.release(), u.get_deleter());

without a dedicated constructor, it would be too easy to forget the
u.get_deleter() part.

Just my opinion,

Ganesh

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

On 10 Okt., 18:42, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> > I note that the draft (n2369) has shared_ptr constructors which take
> > auto_ptr. Since auto_ptr has been deprecated, shouldn't these be
> > changed to take unique_ptr?
>
> Even if auto_ptr has been deprecated, I don't think the constructor with
> the auto_ptr should be removed. However, I agree that adding a new
> constructor that takes a unique_ptr is definetely a good idea,
> especially because such constructor should take the unique_ptr deleter
> into consideration. For example, if u is a unique pointer, then
>
>   shared_ptr p(u);
>
> should be equivalent to:
>
>   shared_ptr p(u.release(), u.get_deleter());
>
> without a dedicated constructor, it would be too easy to forget the
> u.get_deleter() part.

I agree with your proposal to add a corresponding shared_ptr
c'tor accepting a unique_ptr with the above described semantic,
although there might exist one quirk and that is the point that
unique_ptr's deleter is not required to be CopyConstructible.
Of-course, we could simply wait for a nastily choking compiler
at this point;-)

What I really do not understand is that there exists no c'tor

template<class Y> explicit unique_ptr(auto_ptr<Y>& r);

which is astonishing, because unique_ptr is actually
the proposed replacement for auto_ptr. This c'tor seems
IMO more natural than the current one to shared_ptr:

template<class Y> explicit shared_ptr(auto_ptr<Y>& r);

Greetings,

Daniel


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

On Oct 10, 6:42 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Even if auto_ptr has been deprecated, I don't think the constructor with
> the auto_ptr should be removed.

I take the very same position.

> However, I agree that adding a new
> constructor that takes a unique_ptr is definetely a good idea,
> especially because such constructor should take the unique_ptr deleter
> into consideration. For example, if u is a unique pointer, then
>
>   shared_ptr p(u);
>
> should be equivalent to:
>
>   shared_ptr p(u.release(), u.get_deleter());
>
> without a dedicated constructor, it would be too easy to forget the
> u.get_deleter() part.

I just found the following active issue:

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

where Peter Dimov proposes exactly the same extension
(and let shared_ptr now even accept auto_ptr rvalues).

Greetings from Bremen,

Daniel

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

On Oct 10, 10:50 pm, Daniel Kr   gler <daniel.krueg...@googlemail.com>
wrote:
> On 10 Okt., 18:42, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
> wrote:
> > Even if auto_ptr has been deprecated, I don't think the constructor with
> > the auto_ptr should be removed. However, I agree that adding a new
> > constructor that takes a unique_ptr is definetely a good idea,
> > especially because such constructor should take the unique_ptr deleter
> > into consideration. For example, if u is a unique pointer, then
>
> >   shared_ptr p(u);
>
> > should be equivalent to:
>
> >   shared_ptr p(u.release(), u.get_deleter());
>
> > without a dedicated constructor, it would be too easy to forget the
> > u.get_deleter() part.
>
> I agree with your proposal to add a corresponding shared_ptr
> c'tor accepting a unique_ptr with the above described semantic,
> although there might exist one quirk and that is the point that
> unique_ptr's deleter is not required to be CopyConstructible.

Shouldn't MoveConstructible be enough? And that is required.

> What I really do not understand is that there exists no c'tor
>
> template<class Y> explicit unique_ptr(auto_ptr<Y>& r);
>
> which is astonishing, because unique_ptr is actually
> the proposed replacement for auto_ptr. This c'tor seems
> IMO more natural than the current one to shared_ptr:
>
> template<class Y> explicit shared_ptr(auto_ptr<Y>& r);

And of course, all these constructors should be rvalue-only.

Yechezkel Mett


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

Yechezkel Mett ha scritto:
> On Oct 10, 10:50 pm, Daniel Kr  gler <daniel.krueg...@googlemail.com>
> wrote:
>> On 10 Okt., 18:42, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
>> wrote:
>>> Even if auto_ptr has been deprecated, I don't think the constructor with
>>> the auto_ptr should be removed. However, I agree that adding a new
>>> constructor that takes a unique_ptr is definetely a good idea,
>>> especially because such constructor should take the unique_ptr deleter
>>> into consideration. For example, if u is a unique pointer, then
>>>   shared_ptr p(u);
>>> should be equivalent to:
>>>   shared_ptr p(u.release(), u.get_deleter());
>>> without a dedicated constructor, it would be too easy to forget the
>>> u.get_deleter() part.
>> I agree with your proposal to add a corresponding shared_ptr
>> c'tor accepting a unique_ptr with the above described semantic,
>> although there might exist one quirk and that is the point that
>> unique_ptr's deleter is not required to be CopyConstructible.
>
> Shouldn't MoveConstructible be enough? And that is required.

MoveConstructible is required for unique_ptr, but CopyConstructible is
currently required by this constructor:

template<class Y, class D> shared_ptr(Y* p, D d);

Daniel remarks makes sense because I defined the semantic of the
proposed constructor in terms of the existing constructor. We have two
options:

1) require that D shall be CopyConstructible in order to use the
proposed ctor (of course, this does *not* modify the requirement for all
unique_ptrs! it simply means that a unique_ptr whose deleter is
MoveConstructible but not CopyConstructible cannot be "upgraded" to a
shared_ptr).

2) implement the proposed ctor by exploiting some implementation detail
(thus not relying only on the public interface of unique_ptr) so that D
has no additional requirement.

By looking at the shared_ptr implementation in Boost I believe that
approach number 2 is feasible. Actually it seems to me that the
CopyConstructible  requirement could be removed even from the existing
constructor! In fact, the deleter is never copied around, it's used only
to construct the internal sp_counted_impl_pd object and such object is
never copied. I am wondering if CopyConstructible is there because it's
really needed or just because shared_ptr had been designed in a time
where C++ had no move constructors...

Regards,

Ganesh

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

On Oct 12, 3:49 am, Alberto Ganesh Barbati <AlbertoBarb...@libero.it>
wrote:

.

> By looking at the shared_ptr implementation in Boost I believe that
> approach number 2 is feasible. Actually it seems to me that the
> CopyConstructible  requirement could be removed even from the existing
> constructor! In fact, the deleter is never copied around, it's used only
> to construct the internal sp_counted_impl_pd object and such object is
> never copied. I am wondering if CopyConstructible is there because it's
> really needed or just because shared_ptr had been designed in a time
> where C++ had no move constructors...

You are right, MoveConstructible and the rvalue reference did not
exist yet when the specification was written. It looks like
MoveConstructible should be enough for D.

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