Re: setter for deleter in boost::shared_ptr (and alike)
On 25 Sep., 20:29, "Alf P. Steinbach" <al...@start.no> wrote:
What's provided is a pointer to the deleter function pointer or functor
object,
template<class D, class T>
D * get_deleter(shared_ptr<T> const & p);
Since there's no 'const' that pointer can used to change the deleter
function.
That's Very Bad Design(TM), both the "return pointer to innards"
signature, and because the raw pointer and deleter function work as a
unit where the deleter function should not be changed without also
changing the raw pointer, and that should be enforced by shared_ptr.
Checking TR1...
Dang! It's in TR1 too! I can't imagine what they were thinking of,
although no doubt someone will explain that (probably some silly thing
about not breaking hypothetical deleter-changing code based on
boost::shared_ptr, when that could easily be achieved by marking
get_deleter as deprecated and for good measure including it
conditionally on e.g. defined _STD_COMPATIBILITY_GET_DELETER). Let's
just hope the committee re-evaluates this "follow Boost exactly" decision.
It seems a little bit unfair to assume that this is
just based on "follow Boost exactly" strategy. Currently
the draft contains several issues which are underway to be
fixed, and I did not come to the conclusion that this is
related to existing boost (or whatever based) implementations.
Yes, I think that you found an const-incorrect issue in the
draft (and TR1), but I don't think that get_deleter itself
is a design error (despite the const issue, of course). For
some words more on this theme, see below.
Perhaps some bright light on the committee can also notice
* the practical utility of providing standard named destruction
functions for object and array, say, functions std::destroy and
std::destroy_array (which one can be-'friend' in classes that force
dynamic allocation by having inaccessible destructor, use address of and
place in collections, and so on).
In TR1 2.2.3.2/1 "shared_ptr destructor" the last point would then be
"- Otherwise, *this /owns/ a pointer p, and destroy(p) is called."
Then in C++0x one could write e.g.
class Foo
{
template< typename T > friend void std::destroy( T const* );
protected:
virtual ~Foo() {}
public:
Foo( int blahblah );
Foo( std::string const& s, double d );
Foo( Whatever const& );
};
int main()
{
std::shared_ptr<Foo> p( new Foo( "Hi", 3.14 ) );
//...
}
and have a guarantee that Foo instances are dynamically allocated,
useful in e.g. expression trees and other graph structures.
I'm not sure whether I do correctly understand your proposal
or not, so please forgive the following questions, if they
seem self-explaining to you (Belief me, I don't want kidding
you!).
First, *if* I correctly understand your idea, then Foo does
not encapsulate itself stronger by using std::destroy
compared to delete, because the expression
std::destroy(new Foo(42));
would be well-formed - so what is the win compared to an
hypothetical non-existing std::destroy and
delete new Foo(42));
instead (with a publicly available destructor in this
case)? I do see the point that there cannot exist Foo
objects of automatic storage duration, but this is
similarily easy to realize via the current approach
with a friend deleter of Foo which must be provided
with the shared_ptr c'tor and reset. You can even
ensure, that no-one else but shared_ptr<Foo> can
invoke deleter::operator()(const Foo*) by introducing
an additional friend-"connection" between the deleter
and shared_ptr.
Second, I don't see the relation between std::destroy and
the (deservedly) critized ansatz of get_deleter, would you
mind to explain? I mean, what does std::destroy solve that
exists with get_deleter? I found only a minor argument as
shown below.
But perhaps the best we can hope for, and even that of very very low
probability, is a compromise where they add a 'const' to the result of
get_deleter.
Yes, this should indeed be done. And one might consider to
add another overload of the mutable type:
template<class D, class T> D* get_deleter(shared_ptr<T>& p);
get_deleter is an interesting beast. When I saw it's
declaration for the first time in the boost code, I
immediately thought of the so-called "extension-object"
pattern, see. e.g.
http://tinyurl.com/2xx2wq
(Don't be alarmed, this link will try to open a postscript file).
This might be related to the fact, that during that time
a worked for a while with Eclipse where this pattern is
extensively used. Since the static class "interface" of
the shared_ptr itself is independent on a deleter (for
some good reasons, of-course, and in contrast to e.g.
std::unique_ptr), this approach seems to be quite natural
for that use case. And because valid deleter types can be
rather different, I don't see a very much different choice
to access the deleter than this one.
There is one option - which is quite similar to get_deleter
seen from a farther point - and that would be the route which
std::function took. If you consult the section
[func.wrap.func.targ] or the synopsis of class template
function in [func.wrap.func] of N2369 you will notice that
we have there the following three members:
const std::type_info& target_type() const;
template <typename T> T* target();
template <typename T> const T* target() const;
This is effectivly equivalent to get_deleter - although
completely const-correct. The member function target_type()
does not make sense in the general case for shared_ptr,
e.g. if it will invoke delete to free it's resource, so
this asymmetry of shared_ptr compared to std::function
would be the *only* real pro-argument to consider
std::destroy instead of delete as the "natural" deleter.
Greetings from Bremen,
Daniel
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]