Dave Harris wrote:
In-Reply-To: <1130256273.28161.245978560@webmail.messagingengine.com> atompkins@fastmail.fm (Andy Tompkins) wrote (abridged):
I have read a few times that people sometimes wish that std::vector (or other containers) had a virtual destructor.
Generally when I've wished for that I've also wished for a few other virtual functions. For example, a hook which gets called whenever an item is added to the vector, and another which is called when items are removed. I think a vector which is designed to be derived from would need more than just a virtual destructor. If you are adding a vtable you might as well get some milage out of it.
That's what your class would add, presumably.
On the other hand, I rarely need my container to be polymorphic - at least, not with respect to some library base class like std::vector or boost::virtual_vector. Nor do I usually want my container to have the entire interface of vector. For example, I may not want to allow arbitrary insertion at all. So I tend to write a custom wrapper class that has vector as a private member and just exposes what I need.
But when you *do* want to write a vector (or whatever) interface compliant class, it's a bloody pain to do it for each one you do. His impl has the benefit that you just publicly inherit from this class, and add the extra stuff in, overriding any methods that you want to do differently. (I assume the forwarders will be virtual?)
In general inheriting from anything in the std library has the drawback that it injects unknown junk names into your class. Inheriting from a boost class is hardly better.
Actually, his posted impl doesn't do that.
So overall, I'm not in favour.
-- Dave Harris, Nottingham, UK.
Although I don't think it would be massively useful, I can't see why it couldn't be a neat time-saver, if you are doing a lot of "smart" container stuff, or something. It would be nice if it could be made more general, however C++ has it's limits. -- don't quote this