Boost logo

Boost :

Subject: Re: [boost] Adding polymorphic_value to boost
From: Jonathan Coe (jonathanbcoe_at_[hidden])
Date: 2017-11-28 11:24:54


> On 23 Nov 2017, at 17:15, Thorsten Ottosen via Boost <boost_at_[hidden]> wrote:
>
> Den 23-11-2017 kl. 17:32 skrev Jonathan Coe via Boost:
>>> On 23 Nov 2017, at 15:24, Thorsten Ottosen via Boost <boost_at_[hidden]> wrote:
>>>
>
>>> That's going to use way too much space, make swap/move slow and possibly noexcept(false), give poor reference stability. For that case of not heap-allocating each object in isolation, boost::poly_collection seems much better. So I would stick to the allocate on the heap approach.
>>>
>> One can limit the size of the buffer to make it tolerable (like std::function does) and only use the buffer for types than are noexcept-moveable. Reference stability is not a big concern to me (given the intended uses of the api) but is probably worth documenting.
>> My proposed addition does not have a small object optimisation but I would not wish to rule out adding one.
>
> That certainly should be documented. If one stores a base* somewhere outside the collection, this is quite important to know if one should dare sorting a collection of such objects.
>
> And if we use a small buffer optimization, then we get the peculiar case that reference stability depends on the size of the object.
>
> polymorphic_value will leak the pointer abstraction anyway, so I don't see any point in trying to disguise that.
>
> Some other naming ideas:
>
> poly_value<T>
> base_value<T>
> poly_any<T>
> any<T>
>
> kind regards
>
> Thorsten
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

To clarify, polymorphic_value does not guarantee reference stability. Getting a pointer to the managed resource involves writing non-idiomatic code and the formal wording explicitly encourages implementers to use a small object optimisation.

Thanks for bringing the need to clearly document this to my attention.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk