wt., 16 kwi 2019 o 23:57 Richard Hodges via Boost
Are there real-world examples of well-designed classes who's move assignment operators throw?
I think if I saw that in a code review I'd be inclined to demand a different design choice.
Is there a good reason that variants should support such classes?
Some implementations of std::list throw from their move constructors and default constructors. I understand that the implementation is easier if even an empty list has a dummy node, which requires allocation. Regards, &rzej;
On Tue, 16 Apr 2019 at 17:42, Robert Ramey via Boost < boost@lists.boost.org> wrote:
On 4/16/19 5:41 AM, Larry Evans via Boost wrote:
On 4/16/19 4:28 AM, Jonathan Müller via Boost wrote:
On 16.04.19 03:51, Robert Ramey via Boost wrote:
I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like:
template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ...
struct mother_of_variants{ // some trivial mp11 code };
I did something similar back when I did type_safe::variant: You have a `VariantPolicy` that controls whether the variant can be empty and a has a `change_value()` function that switches the type in whatever way it seems fit.
With that I have a `rarely_empty_variant` that is like `std::variant`, a `never_empty_variant` that assumes move is no-throw (and calls terminate() if they throw) and an `optional_variant` that fully embraces an empty state.
At the time I thought it was a good trade-off, but haven't re-evaluated it since then.
I like this; however, years ago there was some argument about how providing such a policy for smart pointers would be confusing to users. However, I didn't really agree with that argument and the alternative is, AFAICT, not much better: std::variant, or boost::variant2 or libx::variant3 or ...
Right. We could have it both ways. That is the mother of all variants could be used to generate a custom type given the requirements. For those who don't want/need to delve into all the details, we provide a list of specialization for commonly used variants which would probably address 99.9% of users needs.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost