Jeffrey wrote on Saturday, March 19, 2011 at 0:25:08:
no offence but is my english really so bad that almost noone can understand what i am talking about? I don't think so.
thanks for that
If you're adamant about doing this, why don't you just use a delete_ (or, maybe better spelled, release or reset or delete_or_reset) free function that's overloaded both for raw pointers and for smart pointers? I'm not convinced you have a legitimate use case to begin with, but under the assumption that you do, this seems like a better resolution than playing games with the smart_ptr interface...
because if we had an alternative of 'delete_(p)' or the like and 'p.reset()' the latter is definitely preferable but 'delete p' form imho is more natural than both of the above eventually peter dimov gave a strong reason regarding smart_ptr: Peter wrote on Saturday, March 19, 2011 at 0:41:23:
There is a specific compile-fail test in shared_ptr for 'delete p'. The reason that you typically need this to be a compile-time error is that when transitioning a large code base from raw pointers to shared_ptr you usually want the compiler to point these out to you so that you can decide what to do with them.
which i agree with in this particular case but not in the general case regarding smart pointers though it is merely a technical aspect of porting sources ideally when you set the pointer type to be a smart pointer in an existing source code (which worked correctly) nothing should change -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out