Re: [Boost-users] bind with weak_ptr

Subject: Re: [Boost-users] bind with weak_ptr
From: Christopher Pisz (cpisz_at_[hidden])
Date: 2011-10-10 18:23:01

Igor R <boost.lists <at> gmail.com> writes:

> 
> > I read the article. Sadly, I cannot even begin to follow the code.
> 
> What article?
> I posted a *ready-to-use* code there, including main() to test it. You
> don't have to follow it, just copy&paste it.
> (But the code is really short and simple, so if you feel it's unclear
> you're welcome to ask.)

The link you gave.
It contains a couple template classes, from what I understand overload 
operator ->*(), which I've never even seen before. I assume it is simply 
trying to replace the internals of the shared_ptr.

> > I also tried going back to raw pointers and now I get unhandled exceptions
> 
> Of course you'll get segfaults if you access destroyed objects!

Yes, obviously. The problem is predicting when they will be destroyed and 
making sure all outstanding bound calls have already been completed and are 
done with. 

> What I meant there is that you can use raw pointer *tracking* it with
> a separate weak_ptr.

It wouldn't matter if I tracked it or not.
Sure, I can check if the pointer is good before I hand a bind to 
boost::asio::io_service. I can check it again when io_service calls me back. 
However, the crash is going to occur when io_service actually does the 
callback and I have no control there.

> But again, if you think it's too much overhead for your design - just
> copy&paste&use the above code.

I absolutly cannot cut and paste code that I don't understand into a company 
project. It is probably simple to you, because you understand the internals of 
the various boost objects. I do not. I am also overdue for a working solution.

> > So, boost has not built this in yet then, even though there seems to be an
> > aweful lot of demand for it?
> 
> I believe it's just not too generic. Note that it "does nothing" and
> returns a default-constructed result type, when the weak_ptr expires.
> It may be appropriate for your specific case, but it's definitely not 
generic.

I understand the claim that it would be up to the user on how to handle the 
instance no longer existing. Maybe they want to throw an exception, maybe they 
want to do nothing, etc. However, I don't see a way to even be _informed_ of 
the situation in order to handle it at all. At least not without a workaround 
like what you posted. It's not in the boost library itself.