Re: setter for deleter in boost::shared_ptr (and alike)
* Alberto Ganesh Barbati:
Alf P. Steinbach ha scritto:
* Alberto Ganesh Barbati:
Alf P. Steinbach ha scritto:
* Abhishek Padmanabh:
Why doesn't boost::shared_ptr<> provide a setter for the deleter when
it provides a getter?
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.
It's true that with the pointer returned by get_deleter() you can call
non-const functions on the deleter, however you still can't replace it
with another (possibly unrelated) deleter
I see no wording to that effect, neither in TR1 nor the draft standard.
If you would care to cite chapter & verse, please?
The onus of the prove is on you.
You have maintained that given a pointer of type
D* p;
one "can't replace [the referent]", i.e. you say that one can't do
*p = aDValue;
Well that's utter nonsense.
Is this a joke?
[snip]
I agree that this kind of code is embarrassing and that having
get_deleter return a const pointer might be better. However, your
example only proves that you can perform an *assignment*, which is not
the same as *replacing* the deleter, as I were objecting.
The subtlety of this clarification is so great that I'm afraid it's
completely meaningless to me.
Notice that,
in order for your code to work you need that:
1) the type of the new deleter must match the type of the old deleter.
As there is no way to determine such type from the interface, you must
know it in advance.
Yes, that's true and irrelevant.
2) the type of the deleter must be Assignable, but it's only required to
be CopyConstructible. Just provide the deleter a private (deleted?)
assignment operator and you would need to rely onto explicit destruction
and placement new... not the code one can write by mistake and expect it
to work properly.
Yes, it's possible for client code to not assign or prevent itself from
assigning. It's also possible for client code to not do any of a
million things. Or to prevent itself from doing any of a million things.
So, you see, the case you present is a very special one, which does not
actually disprove my original statement.
I'm sorry.
- 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! ]