Re: shared_ptr from auto_ptr in draft
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 ]