so you are saying that the leak cannot be prevented from inside the shared_ptr? What I am doing, is having a method2 execute from method1, no matter what happens to method1 (return without problem, thow an exception). void MakeShit() { ........ if (...) throw std::exception(); ..... .. shared_ptr<void> cleanup_shit(static_cast<void*>(0), bind(&Thread::CleanupShit, this)); .... .. return; } I prefer not to make CleanupShit() a no-throw method so that it can report errors using exceptions.What I am trying to make a point at, is that shared_ptr should either prevent the leak in the first place using a second level of ra2 inside it, or at least assert that I am not supposed to throw inside the custom deleter. From: nevin@eviloverlord.com Date: Sat, 13 Nov 2010 11:14:26 -0600 To: boost-users@lists.boost.org Subject: Re: [Boost-users] boost::bind memory leak 2010/11/13 bit bit <g_rambot@hotmail.com> (which doesn't allocate memory).
>>>>>>>>
That's not true. Check this out.. shared_count.hpp Please don't quote out of context. I stated that bind doesn't allocate memory. It doesn't. shared_count,hpp is part of shared_ptr, not bind. That's what causes the leak. You throwing from a deleter which you know is only called from the shared_ptr destructor is what is causing the leak. If you throw from a destructor, all bets are off. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users