Re: setter for deleter in boost::shared_ptr (and alike)

comp.lang.c++.moderated
Alf P. Steinbach wrote:


Before I start on this one, I would like to say that this is getting boring
and the more interesting discussion is below. Note that I have already
granted you that it is not shared_ptr<> that directly prevents assignment
but the type of the deleter whose invariance, in turn, is guaranteed by
shared_ptr<>, which in effect allows you to create shared_ptr object with
unsubvertable guarantees. What I have argued above is that it does not
follow from there that "you can always assign". Since you seem to have
issues with that, let me expand on if once more.

First, let me take the statement "you can always assign" in its literal
meaning, i.e., saying that

   * get_deleter<D>( x_ptr ) = some_new_value; // line (*)

is always well-formed provided some_new_value is of type D (although it may
incur undefined behavior if get_deleter() returns 0). That however, is just
not true (as shown by deleters with class type and disables assignment) and
no fancy comparison with cars or whatever will change that: there are
instances where the compiler will reject line (*). Therefore the claim
that "you can always assign" is just false in this interpretation.

All that is true is that you can assign to the deleter _if_ the shared_ptr<>
was initialized with a deleter of assignable type. That is the (clearly
true) statement you seem to argue agains.

The reason that this distinction is important is that there is another line
in the code:

   shared_ptr<X> x_ptr ( new X (...), some_deleter ); // line (#)

and that line may be written by somebody else. This is where the car analogy
fails: you are assuming that the cars owner is the only agent. That is not
necessarily the case. The author of line (#) has control over whether
subsequently line (*) will compile or not. That control is an important
feature since, e.g., line (#) can happen in a library and line (*) in a
client of that library. Fact is: whoever hands you the x_ptr (and that might
be someone else) can deny you modifying access to the deleter. The
claim "you can always assign" is therefore false in another interpretation,
as well, namely: you can always chose to use a shared_ptr<> that was
initialized with an assignable deleter. If line (#) is outside of your
control, you cannot.

If neither of the interpretations for "you can always assign" that I
considered are correct, please expand on the wording. I am sure that there
can be no real disagreement on the technical issues here.

[snip]


Where in the draft standard do you find that ranking of design goals? That
seems like something you just impose upon it. In other places of the
standard, we find lots of undefined behavior (although not for the sake of
convenience but efficiency). Thus the standard is known to follow design
goals other that safety and guaranteed behavior every once in a while.

Moreover, with specific regard to shared_ptr<>, the claim that safety is a
main design goal seems false: a much bigger issue (from a safety point of
view) than the one currently under investigation is that upon
initialization

   shared_ptr<X> x_ptr ( factory_X ( some_args ), some_X_deleter );

you are choosing the creation method and the deletion method independently.
More generally, shared_ptr<> only encapsulates deletion but not acquisition
of the pointer, it is oblivious as to where the pointer comes from. That
allows for all sorts of mistakes like

   shared_ptr<Derived> d_ptr ( dynamic_cast<Derived*>( b_ptr.get() ) );

(to be committed by someone who does not know about dynamic_pointer_cast<>).
I do not find any evidence for the claim that shared_ptr<> strives to be a
particularly safe component of the standard library. As far as I can see,
std::list is much safer :-)

Anyway, for the sake of this discussion, I will take the design goals of
safety and guaranteed behavior as agreed on. However, I will add on my own:
flexibility. shared_ptr<> is a library component. I do not want it to get
in the way where it should help me.


Follows from a contested premise. Also, you are slanting the discussion.
Allowing for only one design goal is begging the question. What I argued is
that your proposed counter measure (preventing a change of the deleters
value) does not strike the right balance and is sacrificing an unnecessary
amount of flexibility to gain an unneeded amount of safety. If you discard
all other design goals, you close your mind to discussing tradeoffs.

[discussion of memset vs initialization snipped]

And your point about shared_ptr<> is?

Quite honestly, shared_ptr<> as it stands makes all the guarantees I need.
It allows me to write lines

   shared_ptr< X > x_ptr ( new X (...), X_deleter );

where I can perfectly well argue about the subsequent guarantees. Guaranteed
behavior is all about allowing you to reason what can and what cannot
happen after you set something up. I don't need the "you cannot change the
value of the deleter" guarantee that you seem to propose for that purpose.

Where you have a point is with regard to _safety_ for function pointer type
deleters (when a user creates a class type the makes for a stupid deleter,
the fault lies with the user not with shared_ptr<>, especially since it is
much harder to write a stupid deleter class than a sane one). The behavior
of deleters of function pointer type is of course guaranteed and reasoning
the program code is possible. But once you do the reasoning, you find that
you do not want to go for function pointers in the first place :-)

If the conceptual requirement was added that the deleter be of class type,
one would get the safety and all the guarantees that one needs without any
loss of flexibility (but preexisting code might need to be changed). If you
prevent the value of the deleter to change, client code will have to work
around that. Then you get guarantees stronger than you ever need for a
tangible (but admittedly small) price.

Actually, I have seen something interesting being discussed elsethread:
namely to change the return type of get_deleter to const; and you suggested
to add wording to the effect that const_cast<> should be possible to get
modifying access to the deleter object. With that amendmend, I would be
very happy with that proposal. In fact, with const_casting allowed, a const
return type for get_allocator() would be less of a change and less
restrictive than my idea of requiring deleters to be of class type.

Best

Kai-Uwe Bux

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]