Re: setter for deleter in boost::shared_ptr (and alike)
* Daniel Kr?gler:
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.
Since std::tr1::shared_ptr is exactly the same as boost::shared_ptr, I
think it's justified to assume that the const-correctness error, the
same in both, is simply inherited from the Boost implementation.
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.
The non-const-correct version is, IMO.
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,
Yes, and that's one main point. Given N classes with on average M
constructors each, would you rather write N friend declarations or N*M
factory functions? When it can be easy and simple, why make it
difficult and error-prone?
Another point is of course that with just a slight change of the
standard, or unqualified call of destroy so that Koenig lookup applies,
one may then easily provide a class-specific default delete operation.
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.
No, in that case you're duplicating the specification of deleter, in
client code -- unless you go the N*M factory function route --
Umpteen times, where Umpteen is the number of instantiations of class
Foo, could be hundreds or even thousands. Duplication is evil, and
handing responsibility to client code for invoking the right Magical
Incantation every time is evil. Duplication of magical incantation
Umpteen times is Very Evil(TM): unnecessary work, and error-prone.
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.
Not sure what you mean, technically. But anyway, restriction to a
specific smart pointer for a given class, is a separate issue. One way
is to obfuscate the use of new-expressions so that a simple "new Foo"
will not compile.
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.
What does get_deleter solve? It gives access to the destruction
function for the contained pointer, presumably in order to transfer the
raw pointer and destruction function somewhere else. And to the degree
that that's an in-practice need, it is because shared_ptr offers no way
to specify the destruction other than by providing a destruction
function dynamically, as part of the object. With std::destroy the
custom destruction function can be statically associated with the class.
And when that is known for a class, then there's no need to copy the
destruction function (pointer, functor) at run-time: it's a much cleaner
alternative for most cases I can imagine -- and I gather something
similar could even be devices for per-thread allocators. So that's the
connection, that they address the same need, but more cleanly with
std::destroy. I would want it even if there wasn't a connection,
because the lack of a means to specify destruction function statically
is a design level bug.
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.
A less unclean choice for that particular function would be to separate
its current to jobs: checking, and retrieving.
As member functions:
template< typename D > bool has_deleter() const; // Check.
template< typename D > D const& deleter() const; // Retrieve.
where deleter() throws or calls terminate if there is no D deleter.
An abstract deleter functor where you don't need to know the exact type
would incur about the same overhead as a shared_ptr: it would have to do
essentially the same as a shared_ptr internally. So I'm less sure about
how good or bad it would be to abstract up to that level.
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.
Huh? I don't get what you're trying to say here.
Cheers,
- Alf
--
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?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]