Re: N2369 library defect: Const-incorrect get_deleter function for shared_ptr

* Alberto Ganesh Barbati:


e


Yes, I agree, and originally objected to including option (A) for
exactly that reason, but agreed to include it because it's better to
have all options on the table and not exclude in advance.

Over in [comp.lang.c++.moderated] Peter Dimov now has referred to a
primary use case for get_deleter, <url:
http://boost.org/libs/smart_ptr/sp_techniques.html#another_sp>.

This use case, including the example code offered, is compatible with
get_deleter returning a pointer to const, which seems to be an ideal
solution given the constraint of conforming to the current interface.

The use case of "release" of a unique() shared_ptr then requires a
const_cast, which as you noted (also over in [comp.lang.c++.moderated])
is a good way to discourage that in general, so that it will not be done
accidentally, while still allowing it and flagging it as low-level.

Finally, as I noted in response (over in [comp.lang.c++.moderated] :-) )

1. When get_deleter returns pointer to const object, wording that the
deleter is not stored as more cv-qualified than specified by the client
code should IMO ideally be introduced.

N2315 CURRENT WORDING =A720.6.6.2.1/9 [util.smartptr.shared.const]

   Requires: p shall be convertible to T*. D shall be CopyConstructible.
   The copy constructor and destructor of D shall not throw exceptions.
   The expression d(p) shall be well-formed, shall have well defined
   behavior, and shall not throw exceptions.

and N2315 CURRENT WORDING =A720.6.6.2.10/1 [util.smartptr.getdeleter],

where here "p" refers to the shared_ptr, not the raw pointer owned by
that shared_ptr,

   Returns: If p owns a deleter d of type cv-unqualified D, returns &d;
   otherwise returns 0. The returned pointer remains valid as long as
   there exists a shared_ptr instance that owns d. [Note: It is
   unspecified whether the pointer remains valid longer than that. This
   can happen if the implementation doesn't destroy the deleter until a=
ll
   weak_ptr instances that share ownership with p have been destroyed.
   =97endnote]

leaves it unspecified whether the deleter is stored cv-unqualified or
perhaps with added constness, hence also whether get_deleter will
succeed if the original deleter type was cv-unqualified D, and whether
using the result of a const_cast will have formally defined behavior.

And in passing, the term "owns" is not defined. It's set in italics,
twice, in the paragraph about ~shared_ptr. Whereas the convention in
the standard is to set it in italics where it's (implicitly) defined.

PROPOSED REPLACEMENT of =A720.6.6.2.1/9 [util.smartptr.shared.const]:

   Requires: p shall be convertible to T*. D shall be CopyConstructible.
   The copy constructor and destructor of D shall not throw exceptions.
   The expression d(p) shall be well-formed, shall have well defined
   behavior, and shall not throw exceptions. A copy of d, called the
   shared_ptr's /deleter/, of exact type D (not more or less
   cv-qualified) is stored with the copy of p, i.e. shared between
   shared_ptr instances. The shared_ptr is said to /own/ the copies.

PROPOSED REPLACEMENT of =A720.6.6.2.10/1 [util.smartptr.getdeleter]:

   Returns: If p owns a deleter d of exact type D, returns const_cast<D
   const*>(&d); otherwise returns 0. The returned pointer remains valid
   as long as there exists a shared_ptr instance that owns d. [Note: It
   is unspecified whether the pointer remains valid longer than that.
   This can happen if the implementation doesn't destroy the deleter
   until all weak_ptr instances that share ownership with p have been
   destroyed. =97endnote]

Proposed fix of italics-issue =A720.6.6.2.2/1 [util.smartptr.shared.dest]=
:

   <fix> See below. </fix>

2. It would be Really Really Nice if shared_ptr used std::default_delete
as default, instead of calling delete directly as default.

This would allow static specification of a default delete action for a
class, i.e. a per-class customization, in addition to and allowing one
to avoid using the current per-instance customization of specifying the
delete action at every instantiation of a shared_ptr.

N2315 CURRENT WORDING =A720.6.6.2.2/1 [util.smartptr.shared.dest]:

   1 Effects:
     =97 If *this is empty or shares ownership with another shared_ptr
       instance (use_count()>1), there are no side effects.
     =97 Otherwise, if *this /owns/ a pointer p and a deleter d, d(p) is
       called.
     =97 Otherwise, *this /owns/ a pointer p, and delete p is called.

PROPOSED REPLACEMENT of =A720.6.6.2.2/1 [util.smartptr.shared.dest],

changes are to remove italics and, in the last point, to use default_dele=
te:

   1 Effects:
     =97 If *this is empty or shares ownership with another shared_ptr
       instance (use_count()>1), there are no side effects.
     =97 Otherwise, if *this owns a pointer p and a deleter d, d(p) is
       called.
     =97 Otherwise, *this owns a pointer p, and std::default_delete<T>()(=
p)
       is called. [Note: by default this calls delete p. -endnote]

where in N2315 std::default_delete is defined by =A720.6.5.1.1
[unique.ptr.dltr.dflt].

Cheers,

- Alf

Disclaimer, paraphrasing someone's default code header comment: if the
above is all Good, then it was written by me, otherwise, it's someone
else impersonating me.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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 ]