On Sun, 27 Feb 2005 13:11:11 -0500, christopher diggins wrote
At the risk of going against the entrenched dogma here, I'd suggest there are significant cases where this is a good and useful thing to do. I think the original guidance came from Scott Meyers Effective C++ #14 -- make destructors virtual in base classes. The problem I have with this is that I find there are plenty of situations where I might want to add some convenience functions to an stl container in which the subclass has a trivial destructor (eg: no allocated resources)
I am a little confused here, does MySubClass below have a "trivial" destructor?
MySubClass : MyBaseClass { int x; };
In other if I write:
MyBaseClass* p = new MySubClass; delete p;
No leak here. It's only in the case that you allocate in the subclass that there is a problem.
Do I leak the memory for integer x? And then what happens here:
Baz { ~Baz() { cout << "destroying baz"; } };
MySubClass : MyBaseClass { Baz x; };
MyBaseClass* p = new MySubClass; delete p;
Does the baz get destroyed? I always assumed it should.
I didn't try it, but I believe the memory for Baz will be released but the destructor won't be run. It would get bad if you allocated in Baz which would be easy enough to introduce by accident in a real design. Hence the guidance not to go down this path...
If you want to inherit from, say, vector, do you _really_ want _all_ its public member functions?
Yes, I frequently do.
Jeff
So Jeff, would you find a set of macros for facilitating the inheritance of STL containers useful?
I don't think so. See my other response for how I limit my extensions. Also, I really hate macros for doing these sorts of things because I have to reverse engineer what the macro is doing when I need to read the code. At a minimum that means I need to go to another file, try and grok whether the macro applies to what I'm doing, mentally add in whatever functions/types it creates. I'm getting too old for these sorts of mental gymnastics -- I'd rather have the code just written out. Now if you had policy-based collections that would support full inheritability as an option and implemented standard container interfaces -- that might be interesting ;) Jeff