RE: [Boost-Users] Is intrusive_ptr the thing to use?
The only problem with it currently is that the smart_class MUST be managed with smart_ptrs, if you try to 'delete' it, it will try to delete itself and crash.
This seems like a problem that could be overcome through overloading the "delete" operator. Perhaps if you declared your delete operator as protected (or private), and then made the smart pointers you wanted to use friends? That would force you to use a specific set of smart pointer classes, but that doesn't sound like it would be a problem in your case. It's fixing the symptom rather than the disease, but is better than nothing. Turning runtime errors into compiletime errors is always a Good Thing. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard;
On Mon, Nov 25, 2002 at 03:29:49PM -0800, Mark Storer wrote:
The only problem with it currently is that the smart_class MUST be managed with smart_ptrs, if you try to 'delete' it, it will try to delete itself and crash.
This seems like a problem that could be overcome through overloading the "delete" operator. Perhaps if you declared your delete operator as protected (or private), and then made the smart pointers you wanted to use friends?
I thought of that, but it still wouldn't solve the problem of stack instantiation.
That would force you to use a specific set of smart pointer classes, but that doesn't sound like it would be a problem in your case. It's fixing the symptom rather than the disease, but is better than nothing. Turning runtime errors into compiletime errors is always a Good Thing.
Yeah, it would be nice if there were no errors at all however. I'm sure there is a way to solve the problem and have the smart_class behave nicely in all cases. When I get some more time I might try to work on it. --Stephen
participants (2)
-
Mark Storer -
Stephen Crowley