eggs-cpp / variant Goto Github PK

Hello,

Do you think that it would be possible to have an alternative to the current apply mechanism, which would call an operator()() with no arguments instead of throwing ?

A bit like this (but without the overhead of try...catch) :

template<typename Visitor, typename... Variants>
auto apply_noexcept(Visitor&& v, Variants&&... vars) noexcept
    -> decltype(auto)
{
    try {
        return eggs::variants::apply(v, std::forward<Variants>(vars)...);
    }
    catch(const eggs::variants::bad_variant_access& e) {
        return v();
    }
}


int main() 
{
    eggs::variant<int, float> var;
    struct vis {
            int operator()(int) { return 0; }
            int operator()(float) { return 1; }
            int operator()() { return 2; }
    } v;

    auto res = apply_noexcept(v, var);
    assert(res == 2);
}

This is because sometimes types have a meaningful "null" value, and I find it better to just use the variant's null state, than make a variant<some_null_type, ...>.

Hi,

I'm using Visual Studio 2015 Update 3 and I'm getting this
error. I use the commit 91dae80

Commenting this line (28) make the compilation succeed.

Nesting the nposdefinition forces a cumbersome syntax variant<Ts...>::npos, while nposis independent from any Ts.

Hello,

I have this variant in my code :

eggs::variant<int, bool, float, char, std::string, std::vector<foo>> 

and a few other trivial types.

Now when I write visitors, I try to do them in a "as-generic-as-possible" way :

struct my_visitor
{ 
   template<typename T, typename U>
   auto operator(T&& t, U&& u) 
   { return generic_operation(t, u); }

   template<typename U>
   auto operator(const std::string& s, U&& u) 
   { return string_specific_operation(s, u); }

   template<typename U>
   auto operator(std::string&& s, U&& u) 
   { return string_specific_operation(std::move(s), u); }
};

My problem is : how could I generically write my visitor to match the "trivial" types (let's say matchin std::is_numeric) in my variant so that they are always taken by value, without having to specialize either for all trivial types or for all non trivial types ? Because else I have twice the number of functions generated, and passing int by either const & or && instead of just int does not gain anything.

In

constexpr variant(variant const& rhs);

    Requires: std::is_copy_constructible_v<T> is true for all T in Ts....
    Effects: If rhs has an active member of type T, initializes the active member as if direct-non-list-initializing an object of type T with the expression *rhs.target<T>().

you need to add how the constructor behaves is rhshas no active member.

Hi,

Is there a way to use lambda instead of functor for visitor ? If yes, do you have any example ?

Best regards,
Martin

Hi!

In my Debian Sid machine, GCC 4.9, eggs::variant fails to compile. I get the following error:

../third-party/eggs-variant/include/eggs/variant/detail/storage.hpp:321:16: error: ‘std::is_trivially_copyable’ has not been declared
     using std::is_trivially_copyable;
                ^

The problem is, I reckon, that __GLIBCXX__ == 20150826, and is_trivially_copyable is detected via the following preprocessor directives:

#ifndef EGGS_CXX11_STD_HAS_IS_TRIVIALLY_COPYABLE
#  if defined(__GLIBCXX__) && __GLIBCXX__ < 20150422
#    define EGGS_CXX11_STD_HAS_IS_TRIVIALLY_COPYABLE 0
...

Apparently, __GLIBCXX__ is not monotonic, i.e. minor bugfix upgrades for older versions still get bumped to current date. It's unclear to me what the right solution is here...

Further information:

$ g++-4.9 --version
g++-4.9 (Debian 4.9.3-4) 4.9.3

$ apt show libstdc++-4.9-dev
Package: libstdc++-4.9-dev
Source: gcc-4.9
Version: 4.9.3-4
Installed-Size: 12.4 MB
Maintainer: Debian GCC Maintainers <[email protected]>

Thanks a lot!

eggs::variant is proving invaluable to me but is hard to interpret in a debugger.

It would be useful to provide debugger visualisers such as those for Visual Studio:

https://blogs.msdn.microsoft.com/vcblog/2015/09/28/debug-visualizers-in-visual-c-2015/

or LLDB:

http://lldb.llvm.org/varformats.html

Thanks for your great work on this library.

Do you plan to introduce the support for recursive_wrapper like boost::variant have?
I know, that common wrapping of incomplete types breaks type traits on whole variant type, but imposing constraints on using such variant types makes they still useful.

Using master branch I still see this compilation error (the pull request I sent did not fix this, I couldn't figure out a workaround without rewriting your visitor implementation):

2>G:\eggs.variant\include\eggs/variant/detail/visitor.hpp(45): error C2440: 'initializing' : cannot convert from 'overloaded-function' to 'const function_ptr'
2>          None of the functions with this name in scope match the target type
2>          G:\eggs.variant\include\eggs/variant/detail/visitor.hpp(319) : see reference to function template instantiation 'R eggs::variants::detail::visitor<eggs::variants::detail::_apply<R,F,eggs::variants::detail::pack<>,eggs::variants::detail::pack<_Ty &&>>,R (F,void *,V)>::operator ()<int&&,std::string&&>(eggs::variants::detail::pack<int &&,std::string &&>,size_t,fun2 &,void *&&,_Ty &&) const' being compiled
2>          with
2>          [
2>              R=size_t
2>  ,            F=fun2 &
2>  ,            _Ty=eggs::variants::variant<std::string,int>
2>  ,            V=eggs::variants::variant<std::string,int> &&
2>          ]
2>          G:\eggs.variant\include\eggs/variant/detail/visitor.hpp(320) : see reference to function template instantiation 'R eggs::variants::detail::visitor<eggs::variants::detail::_apply<R,F,eggs::variants::detail::pack<>,eggs::variants::detail::pack<_Ty &&>>,R (F,void *,V)>::operator ()<int&&,std::string&&>(eggs::variants::detail::pack<int &&,std::string &&>,size_t,fun2 &,void *&&,_Ty &&) const' being compiled
2>          with
2>          [
2>              R=size_t
2>  ,            F=fun2 &
2>  ,            _Ty=eggs::variants::variant<std::string,int>
2>  ,            V=eggs::variants::variant<std::string,int> &&
2>          ]
2>          G:\eggs.variant\include\eggs/variant/variant.hpp(1453) : see reference to function template instantiation 'R eggs::variants::detail::apply<R,fun2&,_Ty,eggs::variants::variant<std::string,int>>(F,V &&,eggs::variants::variant<std::string,int> &&)' being compiled
2>          with
2>          [
2>              R=size_t
2>  ,            _Ty=eggs::variants::variant<int,std::string>
2>  ,            F=fun2 &
2>  ,            V=eggs::variants::variant<int,std::string>
2>          ]
2>          ..\..\test\apply.cpp(240) : see reference to function template instantiation 'R eggs::variants::apply<size_t,fun2&,eggs::variants::variant<int,std::string>,eggs::variants::variant<std::string,int>,void>(F,eggs::variants::variant<int,std::string> &&,eggs::variants::variant<std::string,int> &&)' being compiled
2>          with
2>          [
2>              R=size_t
2>  ,            F=fun2 &
2>          ]

I can tell you that reducing the overload set e.g. having only const void * overloads fixes the problem. Or only void * overloads. Mixing the two gives the error.

This bug was also in VS2015 right up until the very most recent CTP release.

Niall

I'd like to use eggs variant to represent recursive data structures like JSON which contain maps or lists of more JSON.

Hello:

The compiler happily accepts the following code:

#include <eggs/variant.hpp>
#include <string>
int main()
{
  eggs::variant<int, bool> foo;
  foo.target<std::string>();
}

couldn't it be made so that target<T> only compiles if the variant actually has a T type ?

The signatures of this class and functions seems wrong.

struct in_place_t {};
template <std::size_t I>
in_place_t in_place(unspecified<I>);
template <class T>
in_place_t in_place(unspecified<T>);

There is a parameter to in_place, but elsewhere there is no argument passed.

How in_place_t can remember the Ior the T?

BTW, where in_place_tis used?

Does Eggs.Variant support element visitation? I've had a look through the reference but can't see any method (except maybe apply, is that what I'm looking for?).

Getting a lot of these (everything works in "permissive" mode and in other compilers):

variant/variant.hpp(127): error C2371: 'eggs::variants::detail::_best_match::overloads<eggs::variants::detail::pack<Ts...>,eggs::variants::
detail::pack_c<::size_t,Is...>>::fun_ptr': redefinition; different basic types
variant/variant.hpp(127): note: see declaration of 'eggs::variants::detail::_best_match::overloads<eggs::variants::detail::pack<Ts...>,eg
  gs::variants::detail::pack_c<::size_t,Is...>>::fun_ptr'
variant/variant.hpp(129): note: see reference to class template instantiation 'eggs::variants::detail::_best_match::overloads<eggs::varia
  nts::detail::pack<Ts...>,eggs::variants::detail::pack_c<::size_t,Is...>>' being compiled
variant/variant.hpp(149): error C2371: 'eggs::variants::detail::_best_match::explicit_overloads<eggs::variants::detail::pack<Ts...>,U,eggs:
:variants::detail::pack_c<::size_t,Is...>>::fun_ptr': redefinition; different basic types
variant/variant.hpp(149): note: see declaration of 'eggs::variants::detail::_best_match::explicit_overloads<eggs::variants::detail::pack<
  Ts...>,U,eggs::variants::detail::pack_c<::size_t,Is...>>::fun_ptr'
 variant/variant.hpp(151): note: see reference to class template instantiation 'eggs::variants::detail::_best_match::explicit_overloads<eg
  gs::variants::detail::pack<Ts...>,U,eggs::variants::detail::pack_c<::size_t,Is...>>' being compiled

Hello,

Is there a way to make multi-visitation with apply() & multiple variant types ?

e.g.

eggs::variant<int, float> v1;
eggs::variant<foo, bar> v2;

struct vis { 
    void operator()(int, foo);
    void operator()(int, bar);
    void operator()(float, foo);
    void operator()(float, bar);
};

eggs::variants::apply(vis{}, v1, v2);

thanks !

The following two line program provokes and error message in the latest version of Clang with Xcode.

#include <eggs/variant.hpp>
static_assert(std::is_literal_type<eggs::variant<int, Dtor>>::value, "variant is not a literal type");

This prevents me from using eggs/variant in a struct created by a constexpr function. My understanding was that one of the motivations of the eggs/variant variant is to facilitate the usage of variants in constexpr functions.

Robert Ramey

Currently eggs-variant has a WITH_TESTS option that I can set when I have eggs-variant included as a sub directory in my cmake project. However, this variable name doesn't obviously belong to eggs-variant, so when I run: cmake -DWITH_TESTS=Off .. it is unclear that I simply do not want to run the variant tests. Maybe naming the variable EGGS_WITH_TESTS or EGGS_VARIANT_WITH_TESTS would be better?

In

constexpr variant& operator=(variant const& rhs);

description, doesn't "otherwise, calls *this = {}" recurse?

The same applies to the move assignment.

So many macro, no elegant simplicity.
Hope you can improve to C++14.

Hi @K-ballo,

I'm currently optimizing a code which uses heavily boost::variant at insane sizes. Switching to eggs cpp is a great thing for us, even though eggs cpp is not yet officially released, because it allows us to have an endless variant, it scales better than increasing mpl sizes ( i.e. no need for custom -DBOOST_MPL_LIMIT_LIST_SIZE=XXX as with Boost.Variant ).

I've been looking into it, and when I take eggs::variants::apply function it looks like it's recursing to unpack the variadic parameter pack. And therefore I get a binary which is of 868Kb, when I reimplement the apply function as below, using another way to iterate over variadic parameter pack from Joël Falcou (c.f. https://www.youtube.com/watch?feature=player_detailpage&v=idPThkw2p6c#t=1984), I get a binary of size 784Kb. Because there is way less symbols generated by the variant visitation, and in our code we visit variants often.

namespace pre { namespace variant { 

  template<typename... Ts>
  using pack_params = eggs::variants::detail::pack< eggs::variants::detail::empty, typename std::remove_cv<Ts>::type...  >;

  template<typename F, typename... Ts, typename std::enable_if<!std::is_same<typename F::result_type, void>::value>::type* = nullptr>
  auto apply(F f, const eggs::variant<Ts...>& variant) -> typename F::result_type {
    typename F::result_type result;
    return std::initializer_list<int>{( (variant.which() == eggs::variants::detail::index_of<Ts, pack_params<Ts...>>::value - 1) 
        ? 
        (result = std::ref(f)(eggs::variants::get<Ts>(variant))),0 : 0)...}, result;

  }

  template<typename F, typename... Ts, typename std::enable_if<std::is_same<typename F::result_type, void>::value>::type* = nullptr>
  auto apply(F f, const eggs::variant<Ts...>& variant) -> void {
    std::initializer_list<int>{( (variant.which() == eggs::variants::detail::index_of<Ts, pack_params<Ts...>>::value - 1) 
        ? 
        (std::ref(f)(eggs::variants::get<Ts>(variant))),0 : 0)...};

  }


}}

I think you have a reason why you implemented the visitation by recursing over the parameter pack, therefore I'm asking you if you were open to a PR implementing visitation this way ?

Naturally I would polish it first, and change the result-type to a functions-traits one.

Or perhaps there is something I don't get right ? I must admit I read through really fast your code, so I may have misunderstood or missed something. But from my analysis and understanding apply would benefit from implementing it this way.

Cheers, 😄

f9bcaf3 fails with unsupported language features errors like:

../include/eggs/variant/detail/pack.hpp:22:9: error: unknown type name 'constexpr'
        EGGS_CXX11_CONSTEXPR bool operator==(empty) const { return true; }

requiring C++14 fixes this but I'm not sure if that's the best way to go. (PR coming).

All mentioned operations, expressed by corresponding special functions, are all the same by its nature.
Say, both copy-construction/assignment and move-construction/assignment is just a copy (in both cases!) of memory from one (source, right hand side) properly aligned and sized storage to another (destination, left hand side) (possibly uninitialized). There is not any difference between all of them. The (imaginary) difference arised when considered some artificial class with forced assymetry in mentioned special functions (i.e. some of them are user-provided or explicitly deleted, but others are defaulted). But such a class can be considered as oxymoron, because having (any) one of copy/move-constructor/assignment operator one can emulate each other absolutely legally by using this single existing special function to copy source memory to destination (or simply using std::memcpy). Hence, it make sense to only consider types with all trivial mentioned special functions or with not trivial of all of them.

I think it means, that (in real life) there is no need to dispatch triviality of all the possible combinations for all four (or even eight, if we consider const && and & along with const & and &&) special functions. If any one of them is not trivial, then all others should be treated as not trivial too (but (instead) maybe converse is right if triviality has logical priority).

What do you think about this?

I'll try to compile eggs::variant with gcc 7.3.1 (devtoolset-7) on linux and got folowing error:

In file included from <...>/variant/include/eggs/variant.hpp:13:0,
                          from <...>/variant/test/swap.cpp:8:
<...>/variant/include/eggs/variant/variant.hpp: In substitution of ‘template<class U, class NoCopy, class NoTag, long unsigned int I, class T, typename std::enable_if<(std::is_constructible<T, U>::value && (! std::is_convertible<U, T>::value)), bool>::type <anonymous> > constexpr eggs::variants::variant<int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::variant(U&&) [with U = int; NoCopy = void; NoTag = void; long unsigned int I = <missing>; T = <missing>; typename std::enable_if<(std::is_constructible<T, U>::value && (! std::is_convertible<U, T>::value)), bool>::type <anonymous> = <missing>]’:
<...>/variant/test/swap.cpp:116:46:   required from here
<...>/variant/include/eggs/variant/variant.hpp:696:13: internal compiler error: unexpected expression ‘I’ of kind template_parm_index
           , typename T = typename detail::at_index<
             ^~~~~~~~

Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccYpdTC0.out file, please attach this to your bugreport.**

With gcc 6 it compiles and works fine.

machine:
centos-release-7-5.1804.el7.centos.2.x86_64
kernel: Linux 3.10.0-862.9.1.el7.x86_64

gcc --version:
gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)