Re: [boost] Is there any interest in a library that provides container

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. 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. 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. So overall, I'm not in favour. -- Dave Harris, Nottingham, UK.

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

On Thu, 27 Oct 2005 20:17:02 +1300, "Simon Buchan" <simon@hand-multimedia.co.nz> said:
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?)
I have come to realize (from so many good responses to my post) that this is what I really want to do. I want a class that has the interface of a vector (or another collection) and add other members (functions and/or data) to it. I have also realized that (for my purposes) I don't require the ability to delete people from a pointer to its base class, I am quite happy to always use people or people*. thus a revised sketch: template <class Type, class Allocator = std::allocator<Type> > class wrap_vector { public: //same constructors as std::vector, that forward to m_vec //same methods as std::vector, that forward to m_vec, eg. size_type size() const { return m_vec.size(); } ... protected: // to prevent using deleting a wrap_vector* // as Gennadiy suggested ~wrap_vector(); private: std::vector<Type, Allocator> m_vec; }; struct person { std::string first_name; std::string last_name; }; class people : public wrap_vector<person> { // add member functions // add member data // overload wrap_vector member functions for different behavior };
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.
I believe that it is the time-saving I was after.
-- don't quote this
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andy Tompkins
participants (3)
-
Andy Tompkins
-
brangdon@cix.compulink.co.uk
-
Simon Buchan