Re: [boost] Deterimining interest in: Optional Polymorphic Value object with Small Object optimization

From: Corrado Zoccolo (czoccolo_at_[hidden])
Date: 2007-10-20 16:15:56

Hi Simon

On 10/20/07, Simon Francis <thejello_at_[hidden]> wrote:
>
> http://opensource.adobe.com/classadobe_1_1poly.html
>
> I already knew adobe poly, when I started writing optional_poly. The aim
is similar, but the approach is completely different.
With Adobe poly, you have to design the interfaces, and write "concept maps"
to specifically to work with it.

Example, from Adobe poly test:

struct poly_measurable_interface : adobe::poly_copyable_interface
{
    virtual double size() const = 0;

    virtual ~poly_measurable_interface() { }
};

/*************************************************************************************************/
// This class template implements the abstract measurable interface in terms
of a type T that
// Models the MeasurableConcept

template <typename T>
struct poly_measurable_instance : adobe::optimized_storage_type<T,
poly_measurable_interface>::type
{
    ADOBE_CLASS_REQUIRE(T, , MeasurableConcept);

    poly_measurable_instance(const T& x)
        : adobe::optimized_storage_type<T,
poly_measurable_interface>::type(x) {}

    poly_measurable_instance(poly_measurable_instance& x, adobe::move_ctor
m)
        : adobe::optimized_storage_type<T,
poly_measurable_interface>::type(x, m) {}

    double size() const
    {
        return MeasurableConcept<T>::size(this->get());
    }
};

/*************************************************************************************************/
// Another boilerplate class, measurable serves as a template parameter to
the poly<> machinery
// tying together the interface and implementation above.

struct measurable : adobe::poly_base<poly_measurable_interface,
poly_measurable_instance>
{
    // No delegating constructors (yet), so we call base constructor
manually
    template <typename T>
    explicit measurable(const T& s)
        : adobe::poly_base<poly_measurable_interface,
poly_measurable_instance>(s)  { }

    measurable(measurable& x, adobe::move_ctor m)
        : adobe::poly_base<poly_measurable_interface,
poly_measurable_instance>(x, m) {}

    // No forwarding in C++, so we do it manually
    double size() const
    { return interface_ref().size(); }
};

typedef adobe::poly<measurable> poly_measurable;

Thanks to all this boilerplate code, you can use the usual dot notation to
access the members of the class.

My approach is different. You don't have to change the interfaces to use
optional_poly (so it is non intrusive with existing hierarchies), and you
don't need all this boilerplate code, but you have to use the -> operator to
access members of the class.
Moreover, optional_poly, as the name suggests, is nullable.

The previous example with optional_poly will simply become:

struct poly_measurable_interface
{
    virtual double size() const = 0;

    virtual ~poly_measurable_interface() { }
};
typedef optional_poly< poly_measurable_interface > optional_poly_measurable;

Corrado
-- 
__________________________________________________________________________
dott. Corrado Zoccolo                          mailto:zoccolo_at_[hidden]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------