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