Boost logo

Boost Users :

Subject: Re: [Boost-users] boost::bind memory leak
From: Nevin Liber (nevin_at_[hidden])
Date: 2010-11-13 16:05:57


2010/11/13 bit bit <g_rambot_at_[hidden]>

> so you are saying that the leak cannot be prevented from inside the
> shared_ptr?
>

I'm saying that throwing from a destructor is incredibly bad programming
practice, and has been known to be bad programming practice for years
(plenty of references on this from the writings of Herb Sutter and Scott
Meyers). The destructor for std::shared_ptr will (in all likelihood at this
point) be marked noexcept under C++0X, which would terminate your program.

> I prefer not to make CleanupShit() a no-throw method so that it can report
> errors using exceptions.
>

Good luck with that. Even assuming there is no memory leak, how would you
make the following work:

    void func2()
    {
        try
        {
            int i;
            shared_ptr<void> shutdown(static_cast<void*>(0), bind(&A::func1,
this));
            shared_ptr<void> goodluck(static_cast<void*>(0), bind(&A::func1,
this));
        }
        catch(...)
        {};
    };

> 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.
>

The latter is obvious from the documentation:

      ~shared_ptr
<file:///opt/local/var/macports/software/boost/1.44.0_0/opt/local/share/doc/boost/libs/smart_ptr/shared_ptr.htm#destructor>();
// never throws

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  (847) 691-1404


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net