   boost::shared_ptr subclassing
  I decided a while ago that boost::shared_ptr is much better than my own pointer class.  The problem I'm having is that it's not a simple drop-in replacement for standard pointers.  shared_ptr::reset(T*) is used instead of operator=(T*).  Why is this?  Is there are particular obstacle in using operator overloading, or is it just stylistic?I'd like to subclass it and overload those operator methods and simplify the custom deallocator for my uses.  Is there anything I should know before I do that?   
Quote:Original post by templewulfIs there are particular obstacle in using operator overloading, or is it just stylistic?It is intentional. It is there for the same reason that the constructor is declared explicit: you don't want to accidentally create a shared_ptr out of a dumb pointer. Why? Because even if there already are a 'set' of shared_ptr that correspond to that address, a new 'set' will be created, with its independent reference count, leading to an eventual catastrophe. Also, keep in mind that operator= is automatically used by the language in a number of places (so yeah, that would be an obstacle).Thus they require you to explicitely state that, yes, you really did want to assign a dumb pointer there.As for them not being a drop-in replacement. Well, once you have a shared_ptr, assignment works alright ... between shared_ptr.Quote:I'd like to subclass it and overload those operator methods and simplify the custom deallocator for my uses.  Is there anything I should know before I do that?I suggest you don't overload them. As for the deallocator, I don't see what you need to simplify: you just pass the function to the shared_ptr constructor and you're done.;  Note that the originators of Boost come from the C++ standards committe and that in similar usage auto_ptr uses ::reset() instead of the operators.Dave   ;  Seconded. I can't think of any "simplifications" that could be made to the custom deallocator portion of the interface that wouldn't lead to bugs of similar subtlety to the bugs inherit in accident use of operator= with a dumb pointer.   ;Quote:Original post by FrunyQuote:Original post by templewulfIs there are particular obstacle in using operator overloading, or is it just stylistic?It is intentional. It is there for the same reason that the constructor is declared explicit: you don't want to accidentally create a shared_ptr out of a dumb pointer. Why? Because even if there already are a 'set' of shared_ptr that correspond to that address, a new 'set' will be created, with its independent reference count, leading to an eventual catastrophe. Also, keep in mind that operator= is automatically used by the language in a number of places (so yeah, that would be an obstacle).Thus they require you to explicitely state that, yes, you really did want to assign a dumb pointer there.As for them not being a drop-in replacement. Well, once you have a shared_ptr, assignment works alright ... between shared_ptr.Quote:I'd like to subclass it and overload those operator methods and simplify the custom deallocator for my uses.  Is there anything I should know before I do that?I suggest you don't overload them. As for the deallocator, I don't see what you need to simplify: you just pass the function to the shared_ptr constructor and you're done.I don't really need to simplify it, but there are a couple of places where I need a no-op dtor, and I wanted to build an option for that right into the class, rather than in a separate include file.If I understand you correctly, then, you're saying that they want you to use a different interface to keep sleepy/unwary programmers from starting a separate reference object.  Not that it necessarily is a problem in itself, so much as indiscriminate operator overloading is susceptible to human error.Well, I guess I'll just stick with shared_ptr and do a few find/replaces.  Thanks, Fruny...EDIT:...and everyone else who, apparently, responds faster than I do!  [grin]   ;Quote:Original post by templewulfI don't really need to simplify it, but there are a couple of places where I need a no-op dtor, and I wanted to build an option for that right into the class, rather than in a separate include file.Unfortunately, providing non-inline functions in header files is slightly problematic. When I had to do something like that, I just wrote my own no-op function.Quote:If I understand you correctly, then, you're saying that they want you to use a different interface to keep sleepy/unwary programmers from starting a separate reference object.  Not that it necessarily is a problem in itself, so much as indiscriminate operator overloading is susceptible to human error.Precisely. That's also one of the reasons behind C++-style casts.   