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