Re: setter for deleter in boost::shared_ptr (and alike)
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* James Dennett:
You *may* be able to assign to it,
There is no "may" about it.
Unless you're talking again about an inaccessible assignment operator,
which has nothing to do with what shared_ptr enforces or not.
Of course it has to do with that. The design of shared_ptr<> opting for
get_deleter and leaving out
template < typename D >
set_deleter( D d )
is enforcing that the type of the deleter cannot be changed. That client
code _can_ disable assignment is a direct consequence of the guarantees
made by shared_ptr.
I'm sorry, that's incorrect.
As long as shared_ptr does not require assignable deleters, a deleter
can be non-assignable.
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.
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.
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.
It really needs no further demonstration, but just to help, consider why
you can't change the contained raw pointer similarly.
Others have issues with that.
May be, but they haven't voiced their technical reasoning or even that
they have issues, and I don't know who they could be; in this thread, it
feels like only Humpty Dumpty word redefinitions have been argued.
The discussion of
whether "replace" means change value or means change object identity is an
irrelevant side issue
Right.
(on which you happen to mistaken, too).
I'm sorry, both parts of that sentence, before and after the comma, are
IMHO incorrect.
I think a difference of opinion over Alberto's use of "replace" as a
purported precise technical term is OK, but I take exception to the
implication of the "too". Be concrete if you have a point.
Alberto has explained what he meant by "replace", a change of type or
object identity, but the wording
"you can call non-const functions on the deleter, however you still
can't replace it with another (possibly unrelated) deleter"
was in direct response to and seemingly meant as a refutation of my
"you can change the deleter function",
i.e. seemingly a response "you can do these other things, but not that"
(for e.g. what does the word "still" refer to? huh?)
and as I replied to him, the notion that you cannot change the deleter
is nonsense, and nobody's argued that ints can be changed into doubles,
nor could it be relevant except as an example that "the design could be
even worse but happily it at least preserves the type"[1], so that (now
explained) special meaning was, to put it mildly, far from evident.
[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.
[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. Anything
can be used in safe ways, even goto. It's the opposite view that is of
interest when we talk about what the design enforces, namely the fact
that it needlessly and rather easily can be used in unsafe ways.
Needlessly: other than those unsafe ways necessitated by its very
nature, e.g. circular dependencies.
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.
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. :-)
So there's really nothing further to discuss until someone steps forward
and /defines/ what is meant by the so far metaphysical "replace" that
isn't "change" -- I've asked many times, but no definition so far.
Recall the definition of "object": it is a region in memory. What is stored
there is the value of the object. The same object can have different values
and calls to non-const member functions or calls to the assignment operator
do change the value of the underlying object, which however, remains the
same region of memory. Just taken literally, assignment does not replace
the object by a different object. This is why assignment does not
invalidate references.
Assignment replaces a value. That's common wording, e.g. Wikipedia's
explanation of assignment "The variable is assigned the computed value,
replacing the prior value of that variable." I'm not a telepath who can
reach into people's minds and see that when respond to "can be changed"
by saying "you can do these /other/ things, but you still cannot
replace", they mean something special that has nothing to do with the
statement they're responding to, and so trivial it's not worth saying.
Now for the deleter in shared_ptr. A hypothetical setter function like
template < typename D >
set_deleter( D d );
would replace the current deleter object by a different object (in the
process, the old deleter object is destroyed, the deleter type may change
and so may the region of memory). The assignment of your example code does
not do that. The assignment simply changes the value.
Yes.
There is nothing subtle about that. It's just a simple consequence of the
definition of "object". That definition gives a criterion of sameness and
therefore allows to deduce the meaning of "replace" (which is supposed to
affect the sameness).
Bah -- see above. Or below. :-)
'Twas brillig, and the slithy toves
Did gyre and gimble in the wabe:
All mimsy were the borogoves,
And the mome raths outgrabe.
"Beware the Jabberwock, my son!
The jaws that bite, the claws that catch!
Beware the Jubjub bird, and shun
The frumious Bandersnatch!"
He took his vorpal sword in hand:
Long time the manxome foe he sought?
So rested he by the Tumtum tree,
And stood awhile in thought.
And, as in uffish thought he stood,
The Jabberwock, with eyes of flame,
Came whiffling through the tulgey wood,
And burbled as it came!
One, two! One, two! And through and through
The vorpal blade went snicker-snack!
He left it dead, and with its head
He went galumphing back.
"And hast thou slain the Jabberwock?
Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!"
He chortled in his joy.
'Twas brillig, and the slithy toves
Did gyre and gimble in the wabe:
All mimsy were the borogoves,
And the mome raths outgrabe.
Cheers, & hth.,
- Alf
Notes:
[1] I'm not sure I agree that changing the type of the deleter would be
a bad idea /given/ that assignment is allowed, I simply don't have an
opion on that, and discussing it would be discussing hypotheticals.
--
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! ]