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://listarchives.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.