|
Boost : |
Subject: Re: [boost] Adding polymorphic_value to boost
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-11-23 07:25:32
> and uniform call syntax are not progressing through the C++ evolution
groups
That is a total shame. It would be such a boon to the language.
On 23 November 2017 at 08:18, Jonathan Coe via Boost <boost_at_[hidden]>
wrote:
>
>
> > 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.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk