Re: setter for deleter in boost::shared_ptr (and alike)
* Abhishek Padmanabh:
On 25 Sep, 23:29, "Alf P. Steinbach" <al...@start.no> wrote:
A getter doesn't hurt and might be useful, e.g. for transferring the raw
pointer + deleter function to some other smart pointer.
[snip]
When you say "transferring", do you mean the original shared_ptr
resets its use_count to 0 or what? If it sets it to 0, it would call
the deleter and in that case the pointer becomes useless in that the
object would be deleted.
With the current design of boost::shared_ptr, if you know that a
shared_ptr has a deleter of type D and you control type D (or type D is
simply a function pointer) then for a shared pointer s where s.unique()
you can extract the wrapped raw pointer and deleter by
if( !s.unique() ) { throw UggaBuggaFooFooFoo(); }
D* pDel = boost::get_deleter<D>( s );
D d = (pDel == 0? noOpD : *pDel);
*pDel = noOpD;
T* pObj = s.get();
// Let s go out of scope, keep d and pObj
For example, s might be the result of calling a factory function, and
the code above part of a constructor for the smart pointer type you want
to immediately transfer the resulting pointer to.
Anyway, that was what I was thinking when writing "transferring"; I
didn't discover the get_deleter thing until trying to respond to your
original article, and, disclaimer (speling etc.): the above code hasn't
been touched by any compiler.
And in case it does not, doesn't it cause
more problems? I only see this beneficial when the target smart ptr
has smaller scope as compared to the original shared_ptr and ownership
of destruction lies with the shared_ptr itself and then the deleter is
rendered useless. I can't see any usefulness. Why burder the
interface?
I don't know why they did that. Perhaps someone originally involved
could answer. From my point of view a clean "extract" member function
(throwing on !unique()) would be more generally useful.
The Boost documentation offers little help, just a hint that the above
was probably /not/ what they were thinking (I know, I should have
checked that before answering the obvious that it could be useful for
transferring, but then at that time I wasn't answering about intentions,
only about what the possible use could be):
<quote>
Q. Why doesn't shared_ptr provide a release() function?
A. shared_ptr cannot give away ownership unless it's unique() because
the other copy will still destroy the object.
Consider:
shared_ptr<int> a(new int);
shared_ptr<int> b(a); // a.use_count() == b.use_count() == 2
int * p = a.release();
// Who owns p now? b will still call delete on it in its destructor.
Furthermore, the pointer returned by release() would be difficult to
deallocate reliably, as the source shared_ptr could have been created
with a custom deleter.
</quote>
Cheers, & hth.,
- 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! ]