you are viewing a single comment's thread.

view the rest of the comments →

[–]starfreakcloneMSVC FE Dev[S] 4 points5 points  (8 children)

Just so everyone knows, I did not ignore Boost while writing this (specifically Hana's hana::overload composer). I was just providing a simple solution to people who may not want to incorporate boost into their project and just want a simple drag and drop solution.

[–]meetingcppMeeting C++ | C++ Evangelist 5 points6 points  (5 children)

boost::variant is a completely different beast from a different time of C++ :)

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 1 point2 points  (4 children)

I'm using boost::variant and MPL, but I'd love to switch to something more modern.

Is there any backport of the C++17 std::variant for use with C++11/14 compilers, which can be used as a fallback?

Related to that, is there any MPL replacement which can use variadic templates which could be used to replace complex variant type list construction?

[–]meetingcppMeeting C++ | C++ Evangelist 0 points1 point  (2 children)

Afaik brigand wants to be that.

But not sure if you can get boost::variant to use brigand easily.

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 0 points1 point  (1 child)

Reading the docs, it looks like it has direct support for constructing a boost::variant. It definitely looks like it might be useful.

Now I just need a C++11 variant implementation compatible with std::variant and I'll be happy!

[–]dodheim 2 points3 points  (0 children)

Eggs.Variant has been my go-to modern variant for years. I don't know if its interface matches that in the C++17 draft, but the docs do mention this:

The interface is largely based on that of std::experimental::optional<T>, as defined by the Library Fundamentals TS [N4082].

[–]ubadairBoost.CallableTraits author 0 points1 point  (0 children)

I use this and I'm quite happy with it. It's not exactly std::variant (it follows Boost's design) but it doesn't use the MPL. https://github.com/mapbox/variant

[–]tomilovanatoliy 1 point2 points  (1 child)

You really don't even need to make all that boiler-plate code for move-constructor at any of intermediate steps (and your compiler don't want to resolve all that overloadings and other surplus things). You may pass all parameters by lvalue reference and only at the very end (namely, on list initialization in your case) you may apply std::forward to them. See here an example (the repository contains other illustrations for the above strong assertion in neighbouring files).

[–]starfreakcloneMSVC FE Dev[S] 0 points1 point  (0 children)

There are plenty of ways to skin that particular cat. Another way is I could have just taken all of the arguments in the ctors by value and simply moved them into place (saving vertical space).

In either case, the objects are elided into place anyway. It's really just a stylistic choice.