On 4/7/19 10:59 PM, degski via Boost wrote:

On Sun, 7 Apr 2019 at 18:44, Robert Ramey via Boost wrote:

...

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.

#include #include <variant>

struct Foo { Foo ( ) = delete; };

template struct safe_variant : public std::variant { static_assert ( std::conjunction::value, "is not trivially constructible" ); };

int main ( ) {

safe_variant sv1; // compiles // safe_variant sv2; // does not compile }

Unless I mis-understand what you mean, this does the trick.

degski

LOL - Looks good to me! So now we have std::variant that is guaranteed to have a valid state with no double buffer BS and no extra overhead. I'll be curious to hear what otherothers have to say about this. Robert Ramey

On 8/04/2019 18:29, Robert Ramey wrote:

LOL - Looks good to me!  So now we have std::variant that is guaranteed to have a valid state with no double buffer BS and no extra overhead.

It's restricted to only trivial types, however, which sharply limits its usability. (Mostly just to primitives and PODs, though that's an oversimplification.) Or did you mean to check is_nothrow_constructible rather than is_trivially_constructible? (Also, for robustness you should check assignment as well as construction.)

On Mon, 8 Apr 2019 at 07:45, degski wrote:

Just now I'm at it:

Well, a bit too quick maybe: #include #include <variant> #include #include namespace mp11 = boost::mp11; struct Foo { Foo ( ) = delete; }; struct Bar { Bar & operator= ( const Bar & ) = delete; }; template struct safe_std_variant : public std::variant { static_assert ( std::conjunction::value, "is not trivially constructible" ); }; template struct safe_boost_variant : public boost::variant { static_assert ( mp11::mp_all::value, "is not trivially constructible" ); }; template struct evensafer_std_variant : public std::variant { static_assert ( std::conjunction, std::conjunction>::value, "is not nothrow constructible or not nothrow copy assignable" ); }; template struct evensafer_boost_variant : public boost::variant { static_assert ( mp11::mp_all, mp11::mp_all>::value, "is not nothrow constructible or not nothrow copy assignable" ); }; int main ( ) { safe_std_variant sv1; // compiles safe_boost_variant sv2; // compiles evensafer_std_variant sv3; // compiles evensafer_boost_variant sv4; // compiles safe_std_variant sv5; // does not compile safe_boost_variant sv6; // does not compile evensafer_std_variant sv7; // does not compile evensafer_boost_variant sv8; // does not compile safe_std_variant sv9; // does compile safe_boost_variant sv10; // does compile evensafer_std_variant sv11; // does not compile evensafer_boost_variant sv12; // does not compile } degski -- *Microsoft, please kill Paint3D*

On 4/8/19 12:29 AM, Gavin Lambert via Boost wrote:

On 8/04/2019 18:29, Robert Ramey wrote:

...

LOL - Looks good to me!  So now we have std::variant that is guaranteed to have a valid state with no double buffer BS and no extra overhead.

It's restricted to only trivial types, however, which sharply limits its usability.  (Mostly just to primitives and PODs, though that's an oversimplification.)

Or did you mean to check is_nothrow_constructible rather than is_trivially_constructible?

I looked at both nothrow and trivial and couldn't figure out the difference between them with spending more time than I wanted to at the time. After, I was just throwing out an idea for discussion. Note that this approach is not really a rival to making a new variant. It's to explicit limited the usage a variant to those situations where there are none of the problems and tradeoffs that implementations of variants have to address. Basicall, I'm giving up on trying to understand all this stuff. I just need something that "just works" in an efficient simple way or "just fails(tm)" if that's not possible. It it just fails, I'll fall back to the "fancy variant" (and spend a lot of time investigating the tradeoffs and error/exception handling requirements) or alter my types so the safe_variant just works.

(Also, for robustness you should check assignment as well as construction.)

Hmmm - interesting point. My goal was to make it impossible for safe_variant to end up in the the dreaded stateless state. I was gathering from the discussions that assignment to variant entailed construction of a new instance of one of the constituent types was key place where the stateless problem can occur. So you're absolutely right in that the checks have to be implemented for all operations which might be used. Robert Ramey

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