Quote:Original post by SiS-Shadowman
I stepped through their code and it seems shared_ptr is more sophisticated than storing a T*/U*.
They have a sp_counted_base that stores the reference counter AND an actual implementation: class sp_counted_impl_<T> : public sp_counted_base that preserves the original type.
Quote:Original post by Burnhard
It's pretty cool actually. Apart from some RAII classes I wrote to give me exception safe surface/vertex buffer/etc. locking objects, I haven't had to define or declare a single destructor in any of my classes.
Quote:Original post by SiS-ShadowmanQuote:Original post by Burnhard
It's pretty cool actually. Apart from some RAII classes I wrote to give me exception safe surface/vertex buffer/etc. locking objects, I haven't had to define or declare a single destructor in any of my classes.
I've been complaining for ages that it sucks to implement the virtual destructor for interfaces/classes, because I usually put it into a cpp file anyways (and in the case of interfaces, this means a second file). But since I use shared_ptr almost exclusively, I don't need to anymore. That's great.
class Interface{public: virtual ~Interface() = 0; // no implementation needed};class Interface{public:};THROWIFNULL(MyBar); // Not entirely unreasonable to check this, is it?Quote:My code contains no destructors (virtual or otherwise), no use of "delete" or "release" or "addref" at all and no use of "new" outside of factory CreateXXXX functions. These are things I see sprinkled around tutorial, sample and example code all of the time. I have a feeling they're used in a lot of production code too. As they're points of failure, I think it's not unreasonable to go the extra mile to develop methods that manage them more robustly.
Quote:Original post by BurnhardMy code contains no destructors (virtual or otherwise)[...]
Quote:Original post by NitageI think you far overestimate the limitations in flexibility that the use of smart pointers imposes (essentially none -- just because you don't use manual lifetime management doesn't mean you can't), and far underestimate the performance difference between refcount-based memory management and an actual GC. I'm totally NOT a fan of an Init() method, but wide use of factory functions returning smart pointers buys you out of most of C++'s manual lifetime management woes while still providing performance well ahead of full GCs.
Burnhard, your way of doing things buys you nothing but causes quite a few problems. My main issue is this though; if you are willing to sacrifice performance and flexibility to such a large degree in a bid to remove leaks, why are you using C++ instead of a garbage collected language?
Quote:Original post by Red Ant
I too agree on the use of RAII, but I'd like to point out that even if you have no raw pointers in your class you still must have a virtual destructor if instances of your class are deleted polymorphically, even if the destructor's body is completely empty.
