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

From: Andy Tompkins (atompkins_at_[hidden])
Date: 2005-10-27 09:35:47

On Thu, 27 Oct 2005 20:17:02 +1300, "Simon Buchan"
<simon_at_[hidden]> said:
> Dave Harris wrote:
> > In-Reply-To: <1130256273.28161.245978560_at_[hidden]>
> > atompkins_at_[hidden] (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