Re: [boost] variant - off topic

On 4/7/19 2:47 AM, Bjorn Reese via Boost wrote:

On 4/3/19 11:27 PM, Robert Ramey via Boost wrote:

...

d) insert your own use case here.  That is, look at your own usages of assignment to these types and see if there is not an easy way to re-factor your code to avoid assignment.

Such refactoring is difficult for state machines where you use a variant to denote the current state.

Actually I see now that the real issue is mutable vs immutable data. I've found that often I had been using mutable data when it was easily possible to use immutable data. This actually surprised me and I changed my style to embrace it which has made my programming better. It's a new style. Non-the-less, it's clear that there are some instances where it's not at all natural to try to eliminate mutable data. So now my outlook as it relates to the usage of variant is a little more nuanced. a) Often/usually, I prefer using immutable data and so the issue of assignment never comes up. Any variant will do the job with pretty much no efficiency issues. b) When necessary to use assignment, problems only appear if one of types can throw on construction (?). If non of my constructors can do this - no problem same as a) above. c) Otherwise I have to dig into all these design issues. At that point I might redesign something so that a) or b) applies. Sooo... I'm thinking a good strategy for me in using a variant type would be simlar to: static_assert(is_trivially_constructible, ""); static_assert(is_trivially_constructible, ""); template using my_variant = variant; my_variant x; Of course seeing this, I'm motivated to make something more elaborate: template struct safe_variant : public std::variant { // for each T static assert that is_trivially_constructible<T> == true }; Which gets trickier. But would be cool if someone wanted to make this. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost