2010/11/13 bit bit
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
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/b...(); // never throws -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404