Re: setter for deleter in boost::shared_ptr (and alike)
Thanks, everyone. I don't know what I was thinking but reset() looks
to be the answer to the problem I was facing. I noticed the single
argument overload and mistook it to be only resetting the pointer
while keeping the deleter intact as previously set. That was, of
course, a mistake.
On 25 Sep, 23:29, "Alf P. Steinbach" <al...@start.no> wrote:
Perhaps some bright light on the committee can also notice
* the practical utility of providing standard named destruction
functions for object and array, say, functions std::destroy and
std::destroy_array (which one can be-'friend' in classes that force
dynamic allocation by having inaccessible destructor, use address of and
place in collections, and so on).
In TR1 2.2.3.2/1 "shared_ptr destructor" the last point would then be
"- Otherwise, *this /owns/ a pointer p, and destroy(p) is called."
Then in C++0x one could write e.g.
class Foo
{
template< typename T > friend void std::destroy( T const* );
protected:
virtual ~Foo() {}
public:
Foo( int blahblah );
Foo( std::string const& s, double d );
Foo( Whatever const& );
};
int main()
{
std::shared_ptr<Foo> p( new Foo( "Hi", 3.14 ) );
//...
}
and have a guarantee that Foo instances are dynamically allocated,
useful in e.g. expression trees and other graph structures.
Yes, that would have been useful as compared to always writing
deleters. Also, one version that did not do anything with the pointer
stored. This would be called in cases where the shared_ptr
"conditionally" points to stack-based objects or non-owned pointers or
objects on the free-store.
What is the use of the getter when we cannot
change it for any reason?
A getter doesn't hurt and might be useful, e.g. for transferring the raw
pointer + deleter function to some other smart pointer.
Now, that I see the various reset() overloads, I still don't see the
use of this getter considering the pointers and its deleter go
together. This deleter is not an ownership or a property of the
shared_ptr<> and hence that is not the source to get it. It must be
got directly from the definition. Getting it from the shared_ptr adds
no convenience.
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. 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?
Best regards!
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]