RE: [boost] polymorphic containers

From: Jeff King (peff-boost_at_[hidden])
Date: 2001-11-16 14:18:35

On Fri, 16 Nov 2001, ERICSSON,JOHAN (A-Sonoma,ex1) wrote:

> 1. Don't allow the poly_ptr to have a NULL value. This simplifies both the
> implementation of poly_ptr and the client significantly. The client no
> longer has to check for a NULL poly_ptr. If the client needs an optional

I wanted to do that at first, but I also wanted poly_ptr to be default
constructible for use with standard containers. I'm not sure if it would
be possible to have a poly_ptr that default constructed a pointer to
'parent'. If parent is an ABC, it won't even compile (whether or not you
try to use the default constructor).

> 2. I didn't understand why you needed to use the create() function to create
> a poly_ptr. I simply use a conversion constructor.
>
> poly_ptr(const T& t):m_pT(t.Clone()){}
> Usage:
> poly_ptr<parent> p(child());

Because I didn't require that the type be Clonable; I only required that
it be CopyConstructible. Thus, construction was something like this:

template <class Base>
class poly_ptr {
  public:
    typedef Base* (*clone_function)(const Base& b);

    template <class Derived>
    struct copier {
      static Base* clone(const Base& b) {
        return new Derived(dynamic_cast<Derived&>(b));
      }
    };

    template <class Derived>
    static poly_ptr<Base> create(Derived* d) {
      return poly_ptr<Base>(d, copier<Derived>::clone);
    }

  private:
    poly_ptr(Base* b, clone_function c) : ptr(b), cloner(c) { }
};

> a. This preserves the value-oriented semantics, as you are not taking
> ownership of a naked pointer. You are copying a value into the poly_ptr.
> This is the same way that the STL containers work. They copy values, they
> don't take ownership.

True. I was thinking of it more in terms of keeping the boost::*_ptr
semantics (accepting a raw pointer).

> b. Perhaps you needed the create() function to customize the signature of
> the Clone() (clone(), copy(), Copy()) method...

Yes. See above.

> Anyways, I think a poly_ptr object still has value over a broader variant
> object. The usage of the poly_ptr is bound to be easier.

Really? I took a look at the variant class; it seems quite friendly (at
least as friendly as poly_ptr). Do you have specific complaints about it
as compared to poly_ptr?

-Peff