get_deleter
function for shared_ptr
Section: 20.3.2.2.11 [util.smartptr.getdeleter] Status: NAD Submitter: Daniel Krügler Opened: 2007-09-27 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [util.smartptr.getdeleter].
View all issues with NAD status.
Discussion:
The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
According to the recent draft N2369, both the header memory synopsis of 20.2 [memory] and 20.3.2.2.11 [util.smartptr.getdeleter] declare:
template<class D, class T> D* get_deleter(shared_ptr<T> const& p);
This allows to retrieve the pointer to a mutable deleter of a const
shared_ptr
(if that owns one) and therefore contradicts the usual
philosophy that associated functors are either read-only (e.g.
key_comp
or value_comp
of std::map
) or do at least reflect
the mutability of the owner (as seen for the both overloads of
unique_ptr::get_deleter
).
Even the next similar counter-part of get_deleter
- the two
overloads of function::target
in the class template function
synopsis 22.10.17.3 [func.wrap.func] or in 22.10.17.3.6 [func.wrap.func.targ] - do
properly mirror the const-state of the owner.
Possible proposed resolutions:
Replace the declarations of get_deleter
in the header <memory>
synopsis of 20.2 [memory] and in 20.3.2.2.11 [util.smartptr.getdeleter] by one of the
following alternatives (A) or (B):
container::get_allocator()
, map::key_comp()
, or
map::value_comp
.
template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
Alberto Ganesh Barbati adds:
Replace it with two functions:
template <class D, class T> D get_deleter(shared_ptr<T> const&); template <class D, class T> bool has_deleter(shared_ptr<T> const&);
The first one would throw if D
is the wrong type, while the latter would
never throw. This approach would reflect the current praxis of
use_facet/has_facet
, with the twist of returning the deleter by value as
container::get_allocator()
do.
Peter Dimov adds:
My favorite option is "not a defect". A, B and C break useful code.
[ Bellevue: ]
Concern this is similar to confusing "pointer to const" with "a constant pointer".
Proposed resolution: