Re: [boost] Adding polymorphic_value to boost

Subject: Re: [boost] Adding polymorphic_value to boost
From: Jonathan Coe (jonathanbcoe_at_[hidden])
Date: 2017-11-23 07:18:02

> On 22 Nov 2017, at 23:31, Phil Endecott via Boost <boost_at_[hidden]> wrote:
> 
> Peter Dimov wrote:
>> You can have
>> 
>>    vector<polymorphic_value<Shape>> v;
>> 
>> and then
>> 
>>    v.push_back( Circle(10) );
>>    v.push_back( Ellipse(10, 15) );
>>    v.push_back( Square(11) );
> 
> Good example.  Yes please.
> 
> There's another way of implementing this, though; rather than
> pointing to the object in the heap you can store it in-place
> by allocating enough space for the largest possible derived
> subclass:
> 
> class Base { ... };
> class Derived: public Base { ... };
> 
> template <typename B>
> class polymorhpic_value_2
> {
>  B base;
>  char enough_space_for_dervided_classes_members[1024];
> 
> public:
>  template <typename D> // requires D is same as or derived from B
>  void operator=(const D& d)
>  {
>    B::~B(this);
>    new (this) D(d);
>  }
> 
> };
> 
> polymorphic_value_2<Base> p;
> Derived d;
> p = d;
> 
> That's just a sketch; many details omitted!  There are some obvious
> advantages and disadvantages of each approach and I'm definitely not
> saying this is better than the pointer-to-heap design.  But I mention it
> for this reason:
> 
> * If your proposed interface for polymorphic_value could also work
>   for this method of implementation, then it is probably a better
>   interface.
> 
>> It's unfortunate we have to use -> instead of . but that's what's available. 
> 
> There have been proposals for operator. ; has this been evaluated to
> see how it would work with them?  Similarly the unified a.b() vs. b(a)
> syntax proposal.
> 
> 
> Regards, Phil.
> 
> 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

The design and wording support a small object optimisation (I have not implemented it though). The utility of polymorphic_value is in supporting open-set polymorphism where the set of types to be supported is not known. As such, it won’t be possible to guarantee the use of the small object buffer but it may be useable for some objects.

Operator dot and uniform call syntax are not progressing through the C++ evolution groups, if that were to change then I’d expect to make changes to polymorphic_value similar to those that would be made for optional.