Re: setter for deleter in boost::shared_ptr (and alike)
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* James Dennett:
[snip]
The point is that there is a definite difference in
guarantees made by
shared_ptr {
template < typename D >
D * get_deleter();
};
and
shared_ptr {
template < typename D >
D * get_deleter();
template < typename D >
void set_deleter( D d );
};
The later would allow replacing the deleter object no matter what. Making
the deleter non-assignable would buy you nothing. That making the deleter
non-assignable isn't pointless is because shared_ptr guarantees the
identity
of the deleter object (although not the invariance of its value).
Largely true: what the client code /can achieve/ by making a deleter
non-assignable is a consequence of the shared_ptr guarantees.
Good. Then we largely agree on that one.
However, whether the client code can assign is independent of the
guarantees. shared_ptr does not prevent assignment. By your own
argument that client code can prevent assignment, it can also enable
assignment, thus, you can always assign.
The _always_ does not follow. You can assign if and only if you did not
disable it. The point is that the design of shared_ptr<> allows you to make
guarantees at initialization
shared_ptr x_ptr ( new ..., some_deleter );
that cannot be subverted later.
There is no "may" about it.
Right, and if I recall correct, I never claimed there is.
No matter what guarantees shared_ptr provide or not, that's still the
case: assignability of the deleter itself has nothing to do with what
shared_ptr enforces or not, but the ability to assign if the deleter is
assignable, the ability to change the effective deleter, /is/ a direct
consequence of lack of enforcement.
It's a consequence of design. I do not see a lack of enforcement because
I do not agree that changing the value of the deleter is a bad idea per
se.
Well. Then I face a very uphill battle in trying to convince you. It
reminds me of some debates about
int a[1000];
memset( a, 0, 1000*sizeof(int) );
versus
int a[1000] = {0};
The first few engagements with the opponent usually goes fine: OK, it
actually is possible, OK, it doesn't generate that bad machine code, OK,
it might even generate nearly as good code as the treasured memset. But
then comes the problem that calling memset is perceived as "freedom",
including the freedom to just copy and paste memset-using code, and
restricting oneself to C++ initialization etc. as a -- restriction.
Convincing someone that a restriction can be Good is almost hopeless.
I don't think I've ever succeeded in that.
I fail to see the relation between your example and the question at hand.
Have you seriously suggested a change to the standard that would make it
ill-formed to use memset() ?
We are not discussing whether or not it is good to change the deleter value
obtained by get_deleter(). We are discussing constraining redesigns of
shared_ptr<>. That is unrelated to stuff that could go into guidelines for
coding style.
We should not loose sight of the main contention that the return type
of get_deleter() being non-const is a design flaw. That has been
claimed by you
Right.
(but not demonstrated).
I'm sorry, that incorrect.
It is. You have demonstrated that there are funny things that can happen
when you change the value of a deleter of type pointer-to-function. You
have not demonstrated that get_deleter() returning a non-const pointer is
at fault:
Consider the following patches to TR1:
a) Changing the return type of get_deleter():
template < typename D >
D const * get_deleter()
b) Changing the conceptual requirement on the deleter:
The deleter shall be copy constructible _and of class type_.
I think both patches would take care of the examples you provided.
Therefore, you have not demonstrated that the fault lies with the return
type.
Well, the first patch, (a), fixes the problem by only changing /the
return type/ (except, as Alberto has remarked over in comp.std.c++, that
it still allows a const_cast; a value return would be preferable).
To me that suggests strongly that the return type is at fault. :-)
So now you are trying to fill in the gaps of your demonstration :-)
Anyway, I am not yet convinced that you located the culprit correctly.
shared_ptr<> takes the deleter by value. It is allowed to make an internal
copy. If your could only get a const pointer to that object, it may
internally be declared as const. In that case, const_casting the result
from get_deleter() is undefined behavior.
I think, patch (a) severely restricts what can be done using statefull
deleters. To me, that indicates that it is going overboard.
On the other hand, that may just be the intention of patch (a), in which
case there is a value statement involved that certain uses of statefull
deleters do not deserve to be possible. I do not agree with that assesment
(see below).
Patch (b) seems to be like throwing out the baby with the bathwater,
complicating the usage, and doesn't fix the problem of emptying that
tub: there remains the problem of stateful deleters that are changed.
Here is the crux of our disagreement. I will address the two issues in turn:
1) complicates usage:
Well, I do not really see how
shared_ptr x_ptr ( X_factory( some_args ), X_deleter() );
is more complicated than
shared_ptr x_ptr ( X_factory( some_args ), &delete_X );
2) not fixing the problem:
The point is, I do not percive modifiability of the deleter as a problem. I
percive it as a possibility for doing fancy stuff, the possibilities of
which should be explored not shut off.
The problem with the current design is, in my opinion, more psychological
than logical. The current design requires client code to take
responsibility at the point of initialization. If you chose a deleter tape
whose values can be changed and where funny things might happen when you
do, you are supposed to know what you are doing because all subsequent
guarantees (or lack thereof) follow from the point of initialization. What
you discovered, is that function pointers are very likely not the thing
that you want here -- maybe unless you also control the code that calls
get_deleter().
What I see is that you spotted a point where shared_ptr<> does not follow
the rule of least surprise. The conceptual requirement to have the deleter
be of class type is just meant to make responsibilities transparent.
All three or four articles before my first appeared in this thread,
explained how having a getter but not a setter is extremely desirable
and is tied directly to the fundamental purpose of shared_ptr.
They argued why a
template < typename D >
set_deleter( D d )
is bad. That is an entirely different matter.
As far as I can see the above is an overly optimistic re-interpretation,
for as far as I can see they didn't argue that at all.
[somewhat convicing evidence for your interpretation deleted]
Well, for starters, they wrote in response to the question why there is no
set_deleter. That is the context of all their answers. However, I am not
really interested in working out the best possible interpretations for
three initial postings. I will grant you this point altogether: (a) you may
actually be correct in your interpretaion, but (b) I fail to see the
relevance: if your interpretation of the initial post is correct, then the
initial posters were just missing a subtle issue and initially made overly
general statements which in the light of the present discussion should be
considered false.
It really needs no further demonstration, but just to help, consider why
you can't change the contained raw pointer similarly.
Uh, I see you're not responding to that plea.
Did you?
No, because I failed to see the analogy. More importantly, the technical
discussion has brought the main issues of our disagreement into focus
already. I still fail to see that the non-const return type get_deleter()
is a flaw. But I do see why a set_deleter() would be.
In the way of convincing you, I think your own conclusions will have
more weight than mine! :-)
They sure do :-)
[snip]
Right. This should be about const-correctness. It has been demonstrated
in code that the non-const return type does not prevent (or make
difficult) safe usage of shared_ptr, i.e., at the point where you say
shared_ptr ptr ( new X ... , my_deleter );
the type of my_deleter is _your_ choice. If it is class type. you
_know_ which operator() will be executed upon deletion. No subsequent
assignmen can void the guarantess you put into this line.
So what exactly is the flaw?
I think you can demonstrate, satisfactorily to yourself, that a
setContainedPointer(T*) function that can be disabled would not prevent,
or make difficult, safe usage of shared_ptr. Simply refrain from using
it. And for good measure, always disable it, and voil?, safe.
Please take a few moments to actually demonstrate that, to your own
satisfaction, before reading on.
Not responsive to the question. You have to distinguish two levels of
client
code: (a) the code that initializes the shared_ptr and (b) the code that
uses the shared_ptr later. Invariance of the deleter object implies that
code of (a) type can make guarantees that cannot be subverted by
subsequent
actions in code of type (b). That would not be true if there is a
set_deleter template. Thus your setContainedPointer(T*) analogy is
missing the point.
Hm. Well, I have discussed the distinction between the levels (a) and
(b) elsewhere in this thread, mostly as a summary, see <url:
http://groups.google.no/group/comp.lang.c++.moderated/msg/ea16321837dd1335>,
and that distinction was part of the background for my plea to think
about it. So you're not entirely missing the point! :-)
You have now filled in some background that I, not very good at
communication, didn't provide.
Now I beg you to go further and consider the argument with that
background in place and in mind.
I considered the argument from the beginning with that background in mind.
That is _why_ I suggested to make the interface of shared_ptr<> stress the
responsibility of client code in initialization by requiring deleters to be
of class type.
I don't think that the background provides any reasons to make the return
type of get_deleter() const or make it return by value.
[snip]
I've demonstrated by actual code that you can change the delete
action, what actually /happens/ when a shared_ptr invokes its deleter,
at will (if there is an accessible operator of course).
That is possible if the type of the deleter is a function pointer. For
class types, the code of operator()(T*) will be executed no matter what
you try.
The point isn't that shared_ptr can't be used in safe ways.
The point is that with the current design you can make guarantees in (a)
type code without requiring (b) type code from refraining voluntarily to
to
funny stuff.
OK, I think I understand what you think I don't grok. Namely, that you
think somehow I didn't understand that shared_ptr allows instantiation
code to provide a non-assignable guarantee. My point is that that
guarantee should be provided by shared_ptr, that one shouldn't have to
write perfect client code and use only perfect client code (such as
perfect factory functions) in order to have that guarantee: a default of
safe versus default unsafe. But in trying to convince you of that I'm
up against the "freedom" v. "restriction" battle mentioned earlier.
Ok, this is an interesting idea. If you are just thinking about changing the
default, I would be very interested. Do you have a suggestion for an
interface that would permit the use case from below?
[snip (dealt with earlier)]
I agree that the ideal would be that you couldn't.
I disagree that this would be idea. Somehow, my previous post did
not get through, so I reproduce the use case here:
template < typename T >
class MyDeleter {
typedef std::tr1::function< void(T*) > command;
std::list< command > bye_bye;
public:
template < typename Command >
void push_command ( Command c ) {
bye_bye.push_back( c );
}
void operator() ( T * t_ptr ) const {
for ( std::list< command >::const_iterator iter =
bye_bye.begin();
iter != bye_bye.end(); ++ iter ) {
(*iter)(t_ptr);
}
free (t_ptr);
}
};
Note that this deleter has an accessible assignment operator. Indeed,
you
can use that to ditch all registered actions, but you cannot use it to
change the deletion from free() to, says, delete[].
Uhm, good point, I didn't think of that: the current shared_ptr design
allows you to dynamically add or remove destruction side-effects, per
contained pointer, without using an extra indirection or wrapper.
On the other hand, I've never encountered that need.
And if this was seemingly really needed, I don't think the extra
indirection (of letting the shared_ptr contain a pointer to a C++ object
doing things in its destructor) or wrapper (of shared_ptr itself), or
perhaps some other solution, would be a prohibitive cost, and it might
even be that a redesign where these dynamically specified destruction
side effects weren't needed, would be to the Good.
Well, that can be a little bit tricky. Putting notification code into the
destructor of the deleted object will notify the clients (who may hold
weak
pointers) at a moment when the destruction of the pointee has already
started. They better refrain form doing things like asking the pointee if
there are any last words to be recorded.
When I mentioned "extra indirection" I meant replacing
shared_ptr -> original pointee
with
shared_ptr -> C++ object -> original pointee
And the other alternative I mentioned is to wrap shared_ptr,
wrapper . shared_ptr -> original_pointee
This, I do not quite understand. How is the wrapper supposed to intercept
the deletion? Or do you think of using a custom deleter that will forward
some action to the wrapper? (Cool, but a little contrived in my opinion :-)
A third alternative is a static map of per-pointee cleanup actions. And
I'm sure there are more ways, for this functionality that I've never
needed and never seen! But that doesn't mean that it isn't a valid use
case when you already have the functionality of current get_deleter, it
just means that to me it isn't very convincing as a use case that
requires something like the current get_deleter.
Instead, one such use case is the transferring of a unique()
shared_pointer's pointer to some other smart pointer (as I've discussed
and exemplified with code earlier; Alberto then reported over in
comp.std.c++ that something similar is done in Boost's Python binding
library, and that that seems to be the only case of actually using
get_deleter found using Google code search).
However, my view of that use case is that it is a specialized usage with
its own very important constraints on the operation, and that this
functionality therefore should be directly supported on its own,
directly (and then treating the raw pointer + deleter as a pair).
Since it is ultimately the shared_ptr that decides when deletion will
happen, the deleter object is the natural point for any clean-up code.
Hm. I nearly always think in terms of destructors doing clean-up. :-)
It's not about cleanup. It's about holders of pointers to the pointee being
notified. If they need to have some final interaction, the destructor of
the pointee is the wrong place.
But anyway, see above.
Hm, I will have to evaluate those alternatives more carefully. As of now, I
remain a little sceptical.
Anyway, if there was an elegant way of granting access to the deleter value
without opening that door by default, then the work-arounds you gave would
not be needed.
Now, that is clearly a use case. It far outweighs, in my opinion, the
possible dangers of using shared_ptr<> with a stupid deleter.
Bah. :-)
Note that the only stupid deleters so far are function pointers. It is
easy
to get rid of them.
Stateful deleters can also be stupid. :-)
Sure, one can always _choose_ to be stupid. It's just that the most straight
forward deleters of class type are not stupid. It takes some effort to come
up with silly ones.
And just to throw in something from the side-line:
I notice that in the C++0x get_deleter is not listed under "modifiers",
but has its own little section, which indicates that it is possibly not
/intended/ as a modifier, that it's current functionality is unintended.
And while I'm at it (the draft), I mentioned earlier that I would dearly
like a std::destroy and a std::destroy_array, used by shared_ptr as
default.
Thus exposing my ignorance of the C++0x draft standard where there is
std::default_delete (object and array versions, a template class) --
now I can say with more weight that if would be really nice if
shared_ptr used std::default_delete as default, instead of delete.
I agree. The default should definitely not be a function pointer but a
non-stupid deleter of class type. However, as far as I can see in n2369,
the type of the default deleter is not specified. The only guarantee is
that it will resolve into a calling
delete p
where p is the pointer passed upon initialization.
One could even think of making the default deleter type a class private to
shared_ptr so that get_deleter<> will always return 0 in this case.
[snip]
Best
Kai-Uwe Bux
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]