🚀 go-pugleaf

Related to the apparent "un-object-orientedness" of STL, one problem we've
run into is the inability to gracefully store abstract objects in a container.

One solution is to wrap the object to be stored in some sort of handle.
For those who like to wrap everything in a "handle", this works well.  For
others, this is quite an inconvenience.

Another solution is to use a container of pointers-to-T.  This, however,
makes for some ugly and dangerous code.

Our solution was to create the templates ``plist'', ``pvector'',
``pset'', etc.  These are containers that meet the requirements of
``list'', ``vector'', etc., but internally use pointers instead of
actual copies of the objects.

We've extended the role of the allocator to include ``T* make_default()'' and 
``T* make_copy(const T&)'' functions.  This way, a ``plist<T>'' (for example)
can meet all the requirements of a ``list<T>'', even if T lacks an actual
default ctor or a copy ctor.

Often, We've found that make_copy is defined as ``{ return t.replicate(); }'',
where ``T* replicate()'' is a virtual function for duplicating and returning a
pointer to the new copy.  We do this so often that, in our plist.h, we
have a:
   template<class T> class plistB<T> : public plist<T,p_allocatorB<T> > {...};
where ``p_allocatorB<T>'' assumes T has a ``replicate'' member function, and
that T cannot be default constructed.  Note that, due to lack of a default
constructor, plistB<T> can't do everything that list<T> can, but this is
usually not a problem.

Also, we have an p_allocatorA<T> which simply does a ``{ return new T(t); }''
for make_copy(), and a ``{ return new T; }'' for make_default().  Our
``plistA<T>'' uses this allocator (our compiler doesn't support default
template args).


We are currently adding some special iterator tags to determine if the
iterator is to one of our "p*" containers.  Using these tags, we should
be able to speed up those algorithms that move elements around within or
between containers (since moving a pointer is almost always faster than
moving an object).  The "p*" container iterators offer the following
additional functions:
    T* get_p();                 // These should always be used together
    void set_p(T*);             //  "
and the "plist" (for example) offers:
    void push_back_p( T* p );                     // ``p'' is deletable
    void push_front_p( T* p );                    //  "
    iterator insert_p(iterator position, T* p );  //  "
    T* pop_back_p();                // Caller must worry about deleting 
    T* pop_front_p();               //  returned value.
    T* erase_p(iterator position);  //  "
All of the above (slightly dangerous) extensions transfer "ownership" of
a deletable pointer between caller and callee.  These extensions are
primarily for use by well-tested algorithms.  The general user would
typically stick to the basic set of (safe) STL-defined routines.


Maybe by using something like this, the original poster would find
STL more OO-friendly.

--Roger Morris
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]