boost variant is not a literal type
I want to use Boost.Variant constexpr function. In order to do this it has to be a literal type - which apparently it isn't. The rule for being a literal type are summarized here: http://en.cppreference.com/w/cpp/concept/LiteralType a boost::variant isn't default constructable so it fails to qualify. Has anyone else had this problem before and managed to solve it in a convenient way? Robert Ramey
On 1/6/2016 5:52 PM, Robert Ramey wrote:
I want to use Boost.Variant constexpr function. In order to do this it has to be a literal type - which apparently it isn't. The rule for being a literal type are summarized here:
http://en.cppreference.com/w/cpp/concept/LiteralType
a boost::variant isn't default constructable so it fails to qualify.
A default constructor is not a requirement of literal type.
Has anyone else had this problem before and managed to solve it in a convenient way?
Constexpr support is a complicated thing for `variant`, and it would require a complete reimplementation of `boost::variant`. The trickiest part is having a trivial destructor. For the gory details have a look at these articles: https://akrzemi1.wordpress.com/2012/12/13/constexpr-unions/ http://talesofcpp.fusionfenix.com/post-20/eggs.variant---part-ii-the-constex... Also note that literal unions are over restricted, and that restricts the kind of member types a literal variant might have. That's CWG2096 http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2096 Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 1/6/16 1:03 PM, Agustín K-ballo Bergé wrote:
On 1/6/2016 5:52 PM, Robert Ramey wrote:
I want to use Boost.Variant constexpr function. In order to do this it has to be a literal type - which apparently it isn't. The rule for being a literal type are summarized here:
http://en.cppreference.com/w/cpp/concept/LiteralType
a boost::variant isn't default constructable so it fails to qualify.
A default constructor is not a requirement of literal type. my mistake
Has anyone else had this problem before and managed to solve it in a convenient way?
Constexpr support is a complicated thing for `variant`, and it would require a complete reimplementation of `boost::variant`. The trickiest part is having a trivial destructor. For the gory details have a look at these articles:
https://akrzemi1.wordpress.com/2012/12/13/constexpr-unions/
http://talesofcpp.fusionfenix.com/post-20/eggs.variant---part-ii-the-constex...
I've read your eggs.variant and it seems exactly what I'm looking for so I cloned. I used CMake to make and xcode project and I've got a couple of questions: a) It doesn't seem to specify CTest, at least my xcode project doesn't have a "RUN_TESTS" target. I try to build the tests and I get error messages like: /Users/robertramey/WorkingProjects/variant/include/eggs/variant/detail/pack.hpp:22:9: Unknown type name 'constexpr' at line which contains "EGGS_CXX11_CONSTESPR" which suggests that I haven't got things setup quite right. a) Am I correct in my understanding that this will provide similar facilities to boost variant in way which supports constexpr? b) Anything I haven't done to run test on and use this library. c) Is there any reason that you haven't submitted this to the Boost Library Incubator? Roebrt Ramey
Also note that literal unions are over restricted, and that restricts the kind of member types a literal variant might have. That's CWG2096 http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2096
Regards,
On 1/6/16 2:23 PM, Robert Ramey wrote:
I've read your eggs.variant and it seems exactly what I'm looking for so I cloned. I used CMake to make and xcode project and I've got a couple of questions:
a) It doesn't seem to specify CTest, at least my xcode project doesn't have a "RUN_TESTS" target. I try to build the tests and I get error messages like:
/Users/robertramey/WorkingProjects/variant/include/eggs/variant/detail/pack.hpp:22:9: Unknown type name 'constexpr'
at line which contains "EGGS_CXX11_CONSTESPR"
which suggests that I haven't got things setup quite right.
I've resolved the above. It requires some CMake jujitzu. Didn't quite work out of the box for xcode Robert Ramey
Robert wrote:
c) Is there any reason that you haven't submitted this to the Boost Library Incubator?
Agustin's reasons in this thread: http://lists.boost.org/Archives/boost/2015/06/223920.php Glen -- View this message in context: http://boost.2283326.n4.nabble.com/boost-variant-is-not-a-literal-type-tp468... Sent from the Boost - Users mailing list archive at Nabble.com.
On 1/6/16 3:09 PM, Glen Fernandes wrote:
Robert wrote:
c) Is there any reason that you haven't submitted this to the Boost Library Incubator?
Agustin's reasons in this thread: http://lists.boost.org/Archives/boost/2015/06/223920.php
Glen
Wow - I think I saw some of the thread but it didn't register with me. This is probably because I wasn't interested in variant at the time. Two things stand out for. a) The proposal to bring back the sandbox - To me that's what the incubator is. b) I cloned it, built it and ran the tests. After a very minor hassle with CMake, Everything worked great. c) So this is definitely something that can/should be in the incubator right now so people can easily find it and experiment with it. The requirements of the incubator are designed to: 1) submit code that actually works so it's worth trying 2) provide the author with useful feedback bug reports, etc. So, to me, this is an absolutely ideal candidate to be in there. As a side note, the documentation isn't particularly easy find. The github project has the mark down but not the html so one has to google around for it. Also there are two articles which have very useful information - but they aren't easy to find either. And one more thing. I added the library into my project - and damn! it seems that eggs::variant::variant<int, std::overflow_error> isn't a literal type!!! that is std::is_literal<variant<int, std::overflow_error> returns false_type. This is the original motivation for looking beyond Boost.Variant. It's essential for me to be able to replace my home brew variant which I want to do. I need this to be part of a constexpr function. Robert Ramey
On 1/6/2016 8:58 PM, Robert Ramey wrote:
On 1/6/16 3:09 PM, Glen Fernandes wrote:
Robert wrote:
c) Is there any reason that you haven't submitted this to the Boost Library Incubator?
Agustin's reasons in this thread: http://lists.boost.org/Archives/boost/2015/06/223920.php
Glen
Wow - I think I saw some of the thread but it didn't register with me. This is probably because I wasn't interested in variant at the time. Two things stand out for.
a) The proposal to bring back the sandbox - To me that's what the incubator is.
+1 That's exactly my position.
b) I cloned it, built it and ran the tests. After a very minor hassle with CMake, Everything worked great.
I'd be interested in know what you did with CMake. Feel free to contact me off-list with the details.
c) So this is definitely something that can/should be in the incubator right now so people can easily find it and experiment with it. The requirements of the incubator are designed to:
1) submit code that actually works so it's worth trying 2) provide the author with useful feedback bug reports, etc.
So, to me, this is an absolutely ideal candidate to be in there.
What about stability? That's my main concern; the other one is what would this cost me? Do I have to adopt boost directory layout, move to boostbook documentation, etc? I have no intention of putting any effort towards that **at this point in the library's lifetime**.
As a side note, the documentation isn't particularly easy find. The github project has the mark down but not the html so one has to google around for it. Also there are two articles which have very useful information - but they aren't easy to find either.
The link to the documentation is on the first line of the README. Generated HTML is kept out of band, as to prevent it from cluttering the commit history. Where were you looking for it? Maybe in the "docs" directory? The README on that directory also links to the documentation. I'm not sure what I could do to improve on that, your input is welcomed. I could add links to the articles too, although the documentation already paraphrases the first one, and the second is just on distracting (and infuriating) implementation details.
And one more thing. I added the library into my project - and damn! it seems that eggs::variant::variant<int, std::overflow_error> isn't a literal type!!! that is std::is_literal<variant<int, std::overflow_error> returns false_type. This is the original motivation for looking beyond Boost.Variant. It's essential for me to be able to replace my home brew variant which I want to do. I need this to be part of a constexpr function.
Well of course, since `std::is_literal<std::overflow_error>` yields `std::false_type`. However, I doubt that you actually want to store an entire exception within the object, perhaps an `std::error_code`? The `expected` proposal might be better suited for this purpose. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
On 1/6/2016 7:23 PM, Robert Ramey wrote:
On 1/6/16 1:03 PM, Agustín K-ballo Bergé wrote:
On 1/6/2016 5:52 PM, Robert Ramey wrote:
I want to use Boost.Variant constexpr function. In order to do this it has to be a literal type - which apparently it isn't.
Has anyone else had this problem before and managed to solve it in a convenient way?
Constexpr support is a complicated thing for `variant`, and it would require a complete reimplementation of `boost::variant`. The trickiest part is having a trivial destructor.
I've read your eggs.variant and it seems exactly what I'm looking for so I cloned. I used CMake to make and xcode project and I've got a couple of questions:
a) It doesn't seem to specify CTest, at least my xcode project doesn't have a "RUN_TESTS" target. I try to build the tests and I get error messages like:
/Users/robertramey/WorkingProjects/variant/include/eggs/variant/detail/pack.hpp:22:9: Unknown type name 'constexpr'
at line which contains "EGGS_CXX11_CONSTESPR"
which suggests that I haven't got things setup quite right.
a) Am I correct in my understanding that this will provide similar facilities to boost variant in way which supports constexpr?
No, the fundamental model of Eggs.Variant is that of a discriminated union while Boost.Variant models a type sum. Those are terms that I made up and that I describe here: http://talesofcpp.fusionfenix.com/post-21/rant-on-the-stdexperimentalvariant...
b) Anything I haven't done to run test on and use this library.
I use CMake to run the unit tests and it Just Works. Perhaps a missing -std=c++11 (or greater) flag?
c) Is there any reason that you haven't submitted this to the Boost Library Incubator?
The library is meant for experimentation only. I will break backwards compatibility or stop supporting compilers I no longer need as I see fit (msvc needs quite a lot of cruft and it still only gets a fraction of the features). Once the library stabilizes I would consider submitting it to the blincubator. Recent experimentation with concepts led me to believe they will be a game changer for the implementation, and that they will make a perfectly transparent discriminated union tractable, so that might be a while. Furthermore, I believe Boost would benefit more from a library tracking the `variant` proposed for standardization (now that we finally have design agreement), and Eggs.Variant is deliberately not that. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
participants (2)
-
Agustín K-ballo Bergé -
Glen Fernandes -
Robert Ramey