- Boost - lists.boost.org

[hana] Lorenzo's Formal review for Hana
by Lorenzo Caminiti 24 Jun '15

24 Jun '15

Hello Glen, Louis, and all, Please find below my review of the proposed Boost.Hana library. > - Whether you believe the library should be accepted into Boost Yes, Boost.Hana should be accepted into Boost. I decided to make my acceptance vote unconditional. However, I do have some concerns and I hope these can be addressed if Hana is in fact accepted into Boost. I marked these concerns as "[CONCERN]" below. > - Your name Lorenzo Caminiti. > - Your knowledge of the problem domain. I have been using C++ Template Meta-Programming (TMP) for 10+ years now. I routinely maintain ~23,000 lines of production code that extensively uses Boost.MPL, Boost.Fusion, and a TMP-based serialization mechanism (among a number of other Boost libraries) -- compilation times are a *huge* issue with this code! > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design The library API seems reasonable, consistent, and powerful. * [CONCERN] Assertions should be renamed from ..._CHECK to ..._ASSERT (to be consistent with assert, static_assert, BOOST_STATIC_ASSERT, BOOST_MPL_ASSERT, etc.). * Is there a ..._MSG version for the assertion macros? (These should probably just variadic macros where a second optional parameter represents the error message to display in case the asserted condition if false.) * The following is very nice! auto has_toString = is_valid([](auto&& obj) -> decltype(obj.toString()) { }); I've been wanting to do the above at function scope for a long time (so I can program it within the function where I actually need it). Now with C++14 generic lambdas we finally can :) Also this is very nice! template <typename T> std::string optionalToString(T const& obj) { return if_(has_toString(obj), [](auto& x) { return x.toString(); }, [](auto& x) { return "toString not defined"; } )(obj); } Somewhat similar to my static_if (renamed call_if, after Vicente's suggestion) proposal using C++14 generic lambdas: http://boost.2283326.n4.nabble.com/static-if-Is-there-interest-in-a-static-… BTW, how would you program the following possible implementation of std::advance in Hana? template<typename Iter> struct is_random_access_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::random_access_iterator_tag > {}; template<typename Iter> struct is_bidirectional_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::bidirectional_iterator_tag > {}; template<typename Iter> struct is_input_iterator : std::is_same< typename std::iterator_traits<Iter>::iterator_category, std::input_iterator_tag > {}; template<typename Iter, typename Dist> void myadvance(Iter& i, Dist n) { Iter *p = &i; // So captures change actual pointed iterator value. call_if<is_random_access_iterator<Iter> >( std::bind([] (auto p, auto n) { *p += n; }, p, n) ).template else_if<is_bidirectional_iterator<Iter> >( std::bind([] (auto p, auto n) { if(n >= 0) while(n--) ++*p; else while(n++) --*p; }, p, n) ).template else_if<is_input_iterator<Iter> >( std::bind([] (auto p, auto n) { while(n--) ++*p; }, p, n) ).else_( std::bind([] (auto false_) { static_assert(false_, "requires at least input iterator"); }, std::false_type()) // Use constexpr value. ); } * This macro: struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::string, name), (int, age) ); }; Will it work even if the data member types contain commas? For example, the following is supported, correct? (It should be because these can use variadic macros...) struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>, name), (int, age) ); }; P.S. These sort of macros /could/ be implemented as follows if users found this syntax to be more readable (but maybe not...): struct Person { BOOST_HANA_DEFINE_STRUCT(Person, (std::map<int, char>) name, (int) age, ); }; * [CONCERN] The docs say: "Hana's design assumes that most of the time, we want to access all or almost all the elements in a sequence anyway, and hence performance is not a big argument in favor of laziness." Especially given that other well-established libraries like Fusion addressing the same problem domain have gone in favor of laziness instead... Is this a good assumption? If so, why? * [CONCERN] The docs say: "By default, Hana assumes functions to be pure. A pure function is a function that has no side-effects at all." Will this assumption limit what users will be able to do with Hana? Do MPL and Fusion relay on a similar assumption? Yes/no, why... * [CONCERN] I would prefer a descriptive name for the library instead of Hana. I am well aware that Phoenix, Spirit, Wave, etc. are examples of non-descriptive names in Boost. I consider those bad naming choices and I would not follow them. Changing the library name should only take a few days (maybe 2-5 days... especially with tools like grep and sed) so that should not be a problem. Others pointed out that there might be copyright/trademark issues with the name "Hana". The possibility to have to change such name at some point /after/ the library has been released in Boost would be a disaster for the users... such risk should be avoided. Possible names? typeval (given the library is about "TYPEs as VALuses", plus the similar, already familiar, name std::declval) meta metaval metaexpr generic (assuming Matt Calabrese is no longer planning to use this) ... * [CONCERN] Rename Map, Range, etc. to map, range, etc. (all lower case). In Boost and STL capital letters are only used for template parameters, and maybe concepts. (If it is important to distinguish that those are tags (I don't think so) then name them map_tag, range_tag, etc. but still no capital letters.) * [CONCERN] is_empty, length, and few other names should be changed to empty, size, etc. to match STL naming conventions (so I don't have to remember different names for the same thing). > * Implementation Some code can be optimized, but the author already mentioned he will look into that this summer. I did not see any specific issue otherwise. > * Documentation * [CONCERN] The documentation will be much (much!) more readable is the "hana" namespace was not stripped away. Please write hana::..., mpl::... (if not the full boost::hana::..., boost::mpl::...) in the docs. * The docs say: "Notice how we cast the result of x.member to void? This is to make sure that our detection also works for types that can't be returned from functions, like array types." auto has_member = is_valid([](auto&& x) -> decltype((void)x.member) { }); But obviously, the following (without the cast) would work too, correct? auto has_member = is_valid([](auto&& x) -> decltype(x.member, void()) { }); * I would expect the following example to use operator|| instead of or_: auto ts = filter(types, [](auto t) { return or_(is_pointer(t), is_reference(t)); }); * Performance graphs would be more readable if they always used the same color for the same entity. For example, sometimes mpl::vector is blue, other times it is orange... * Why the "Runtime performance of reverse on normal container" for fusion::vector stops at "Number of elements" = 50? > * Tests > > * Usefulness * If not for anything else, I will use this library for its SFINAE facilities. Second, I will use this library in production code for its improved compilation times (assuming these can be confirmed on MSVC). Finally, I am curious to use this library in general because it seems it will improve my meta-programming, also making easier to read. * [CONCERN] The author should be committed to support the library on GCC and MSVC once that becomes feasible, even if that requires a good deal of workarounds. For example, Boost.Preprocessor is full of MSVC workaround (because MSVC preprocessor is still not standard compliant... after 30+ years of existence of the C preprocessor). Maybe MSVC will never be 100% C++14 standard compliant... I don't know. But I do know that if this library is not ported to MSVC at some future point, I won't be able to use it in my production code. I do hope that adoption into Boost will push vendors to support C++14 constructs used by this library TMP techniques. I also hope the author is committed to do whatever it takes to make the library work on MSVC. * [CONCERN] What compiler was used to measure performance? CLang? I hope the promised performance gains (especially compile-time reductions) will be there for GCC, and especially later also for MSVC. If not, that will significantly limit my motivation on using this library in production code. TMP compilation times are largely dependant on specific compiler implementations of C++ template machinery which might vary significantly from vendor to vendor. Therefore, at the moment I only know that the library is expected to compile faster on Clang, but unfortunately that does not tell me anything about expected compilation time improvements on GCC, and even less on MSVC... > - Did you attempt to use the library? If so: > * Which compiler(s)? Clang. > * What was the experience? Any problems? Overall, pretty good experience. No specific issue to report a part from what already noted. > - How much effort did you put into your evaluation of the review? A total of about 2 days between reading docs, playing with some examples, and looking at the code a bit. My thanks to Luis for his outstanding work with this library! --Lorenzo On Wed, Jun 10, 2015 at 2:19 AM, Glen Fernandes <glen.fernandes(a)gmail.com> wrote: > Dear Boost community, > > The formal review of Louis Dionne's Hana library begins today,10th June > and ends on 24th June. > > Hana is a header-only library for C++ metaprogramming that provides > facilities for computations on both types and values. It provides a > superset of the functionality provided by Boost.MPL and Boost.Fusion > but with more expressiveness, faster compilation times, and faster (or > equal) run times. > > To dive right in to examples, please see the Quick start section of the > library's documentation: > http://ldionne.com/hana/index.html#tutorial-quickstart > > Hana makes use of C++14 language features and thus requires a C++14 > conforming compiler. It is recommended you evaluate it with clang 3.5 or > higher. > > Hana's source code is available on Github: > https://github.com/ldionne/hana > > Full documentation is also viewable on Github: > http://ldionne.github.io/hana > > To read the documentation offline: > git clone http://github.com/ldionne/hana --branch=gh-pages doc/gh-pages > > For a gentle introduction to Hana, please see: > 1. C++Now 2015: > http://ldionne.github.io/hana-cppnow-2015 (slides) > 2. C++Con 2014: > https://youtu.be/L2SktfaJPuU (video) > http://ldionne.github.io/hana-cppcon-2014 (slides) > > We encourage your participation in this review. At a minimum, kindly > state: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance > - Your name > - Your knowledge of the problem domain. > > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design > * Implementation > * Documentation > * Tests > * Usefulness > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? > - How much effort did you put into your evaluation of the review? > > We await your feedback! > > Best, > Glen > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[graph] depth_first_visit_impl
by Michael Marcin 24 Jun '15

24 Jun '15

I was doing some work with depth_first_search and came across some issues that seem surprising with the implementation. First vis.finish_edge doesn't seem to ever get called on msvc. Second changing the code to call finish_edge directly instead of through the call_finish_edge machinery seems to result in incorrect edges being finished. Third the implementation of depth_first_visit_impl pushes into a std::vector stack even for vertices with no out_edges. If I have a graph with a large number of vertices but few or no edges this seems bad. This seems to force a dependency on optional as well. Finally the loop as written should probably be a do..while since the stack will never be empty on the first test. I attached a patch that addresses the second and third issues. The tests continue to pass for me with this change.

1 0

[Hana] Formal review
by Bruno Dutra 23 Jun '15

23 Jun '15

Dear all, Following is my review of Hana. - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, absolutely, but please read on. - Are you knowledgeable about the problem domain? I've been playing with metaprogramming as a hobby since 2011 when I first came across Boost.MPL. I experimented with a library that implements the unification algorithm at compile time using Boost.MPL for a long time, on and off, and recently I've decided giving a shot at my own implementation of a C++11 version of Boost.MPL. - What is your evaluation of the design? The design seems to be very general and abstract, based on formal mathematical concepts. I've had my dose of FP through SML and lisp, however I've never dug deep into category theory, so I won't venture into judging the way these abstract concepts were translated to C++, but all looks sound to me. I'm very fond of the way type computations are carried out by value through the use of type<> and decltype(). Such an ingenious simplicity. Once one gets it, one realizes how beautifully it merges value and type computations into one. I also like very much the design of compile time constants, their custom _c suffix and operators. To me, that is material for standardization. I would like to point out however, that from the point of view of someone who has basically solely done C++ his entire life, just like myself, Hana can look *very* unfamiliar. I understand it is mostly my fault for not properly having learnt FP before, however I believe I'm not alone among average C++ programmers, so I fear this could prevent many potential users from adopting Hana, simply because one tends to stick to things that look familiar to one. Now I'm not sure that is any easy way around this unfamiliarity. I've seen others pointing out that names could better reproduce the C++ standard library (to what I agree) and perhaps that's indeed all one could do to tighten the gap that separates Hana from mainstream C++ libraries. At any rate, I just felt I should stress this point, to make sure it is not underestimated. - What is your evaluation of the implementation? I've just briefly peeked at the code base out of curiosity and it looks pretty clean and organized. The use of global function objects however intrigues me, why not free functions? I've also found myself stumbling on variable templates. Perhaps that's just me, but really I find they make everything so cryptic. Anyways, I guess it's not Hana's fault to make arguably good use of something that is part of the language. - What is your evaluation of the documentation? I find myself blindly using the search button in hope to find whatever I'm looking for more often than I'd rather do, but perhaps it's just a matter of getting used to how the documentation is organized. One thing I'd like to see improved is the alphabetical index. I'd expect it to be thorough, but at least "is_a" is missing, so I assume a rationale exists to decide what goes there? I think it would be better to list everything exhaustively, so users may rely on the browser's find tool to explore the library. - What is your evaluation of the potential usefulness of the library? At first I was afraid Hana were too academical and abstract to be a good tool for getting down to business, but after playing with it a little bit I can see that, once one gets its design, it does make metaprogramming quite straightforward. I believe however that most users will attain to a very limited subset of functionalities in order to just get their tasks accomplished. So much so, that I'd strongly advise Hana to be split into one highly specialized tool for straightforward metaprogramming and another more abstract halve providing the more generic concepts. This could ease user experience considerably, reducing the novelty presented by Hana and thus tightening the gap I've mentioned before. - Did you try to use the library? With what compiler? Did you have any problems? Yes on Clang 3.6.1. I tried to implement the unification algorithm [1] at compile time using Hana and, though I haven't actually finished, I could see it would be straightforward. In fact I gave up on it when I found a bug which prevented the construction of optional maps, but not too long after I contacted Louis and opened an issue [2] it seems to have already been fixed on develop branch. I didn't test the fix myself though. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 4 hours reading the documentation, another 4 hours trying the library and about 2 hours to write this review. *Bruno C. O. Dutra* [1]: https://en.wikipedia.org/wiki/Unification_(computer_science) [2]: https://github.com/ldionne/hana/issues/149

3 4

[test] Re: [Boost-testing] Develop branch test runners crashing
by Rene Rivera 23 Jun '15

23 Jun '15

Please fix ASAP. On Tue, Jun 23, 2015 at 8:32 AM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? > > _______________________________________________ > Boost-Testing mailing list > Boost-Testing(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-testing > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

Re: [boost] [test] Develop branch test runners crashing
by Andrey Semashev 23 Jun '15

23 Jun '15

On Tue, Jun 23, 2015 at 4:32 PM, Tom Kent <lists(a)teeks99.com> wrote: > Sometime between 22:30 and 03:30 last night (pacific time) all the develop > tests started crashing on windows and linux. > > The tail of results/bjam.log is: > > notice: iostreams: not using bzip2 compression > notice: iostreams: not using bzip2 compression > ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test > *** argument error > * rule boost.test-self-test ( test-rule : test-suite : test-name : > usage-variant ? : pattern_file * : source_files * : extra-libs ? : > extra-options ? ) > * called with: ( : ../doc/examples : : included : : > /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp > ) > * missing argument test-rule > ..\libs\test\test\Jamfile.v2:18:see definition of rule > 'boost.test-self-test' being called > (builtin): in sequence.transform > ..\libs\test\test\Jamfile.v2:162: in modules.load > D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile > D:/t08/run/boost_bb/src/build\project.jam:64: in load > D:/t08/run/boost_bb/src/build\project.jam:145: in project.find > D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really > D:/t08/run/boost_bb/src/build\targets.jam:474: in find > D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build > D:/t08/run/boost_bb/src/build\targets.jam:270: in > class(a)project-target.generate > D:/t08/run/boost_bb/src\build-system.jam:707: in load > D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import > D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build > D:\t08\run\boost_root\boost-build.jam:17: in module scope > > Any thoughts? Looks like a Boost.Test issue.

1 0

Develop branch test runners crashing
by Tom Kent 23 Jun '15

23 Jun '15

Sometime between 22:30 and 03:30 last night (pacific time) all the develop tests started crashing on windows and linux. The tail of results/bjam.log is: notice: iostreams: not using bzip2 compression notice: iostreams: not using bzip2 compression ..\libs\test\test\Jamfile.v2:59: in docs-example-as-test *** argument error * rule boost.test-self-test ( test-rule : test-suite : test-name : usage-variant ? : pattern_file * : source_files * : extra-libs ? : extra-options ? ) * called with: ( : ../doc/examples : : included : : /D:/t08/run/boost_root/libs/test/doc/examples/boost_test_bitwise.run-fail.cpp ) * missing argument test-rule ..\libs\test\test\Jamfile.v2:18:see definition of rule 'boost.test-self-test' being called (builtin): in sequence.transform ..\libs\test\test\Jamfile.v2:162: in modules.load D:/t08/run/boost_bb/src/build\project.jam:325: in load-jamfile D:/t08/run/boost_bb/src/build\project.jam:64: in load D:/t08/run/boost_bb/src/build\project.jam:145: in project.find D:/t08/run/boost_bb/src/build\targets.jam:452: in find-really D:/t08/run/boost_bb/src/build\targets.jam:474: in find D:/t08/run/boost_bb/src/build\targets.jam:305: in targets-to-build D:/t08/run/boost_bb/src/build\targets.jam:270: in class(a)project-target.generate D:/t08/run/boost_bb/src\build-system.jam:707: in load D:\t08\run\boost_bb\src/kernel\modules.jam:295: in import D:\t08\run\boost_bb\src/kernel/bootstrap.jam:139: in boost-build D:\t08\run\boost_root\boost-build.jam:17: in module scope Any thoughts?

1 0

[coroutine2] Difference between coroutine and coroutine2
by Aaron Levy 23 Jun '15

23 Jun '15

Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine? -- Aaron Levy aaron.levy(a)yandex.com

5 7

[Optional] Monadic bind
by Tobias Loew 23 Jun '15

23 Jun '15

While playing around with boost::optionals I had code like the following struct A { ... int i; ... }; boost::optional a; // do something with 'a' // optional-projection to a::i boost::optional<int> a_i; if(a) a_i = a->i; which seemed quite verbose for something that's rather natural in functional languages: boost::optional is a monadic structure, which lifts a type T by extending it with a new bottom-element (represented by the empty optional<T>), thus it should also have a "bind" and a "map"-equivalent, which could be implemented for instance as as member functions of optional template<class B> auto bind(B&& binder) const -> boost::optional<typename std::decay<decltype(std::bind(binder, get())())>::type> { if(this->is_initialized()) { return std::bind(binder, get())(); } else { return boost::none; } } and template<class B> auto map(B&& f) const -> boost::optional<typename std::decay<decltype(std::bind(f, get())())>::type> { if(this->is_initialized()) { return std::bind(f, get())(); } else { return boost::none; } } where map lifts f from A->B to optional -> optional< B > and applies 'this' to it. This would allow things like boost::optional a; auto a_i = a.map(&A::i); // "optional-projection"; type of a_i is boost::optional<int> Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Optional-Monadic-bind-tp4677431.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 7

[test] Where we are with the new version?
by Vicente J. Botet Escriba 23 Jun '15

23 Jun '15

Hi, I'm wondering if the new Boost.Test will be merged one day to the master branch. Best, Vicente

3 5

[config] 'requres' doesn't take differing -std into account
by Peter Dimov 22 Jun '15

22 Jun '15

I have, in my user-config.jam, using gcc ; feature.subfeature toolset gcc : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-gcc:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-gcc:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-gcc:std>cxx14 : <cxxflags>-std=c++14 ; using clang : : : <cxxflags>-Wno-variadic-macros <cxxflags>-Wno-c99-extensions ; feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 : optional composite propagated ; feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; This allows me to use toolset=clang (without -std) and toolset=clang-cxx11 (with -std=c++11). The 'requires' rule however caches the results of the configuration check when I run with toolset=clang, and then when I rerun with toolset=clang-cxx11, it uses the cached values, which is wrong. I use something like run test.cpp : : : [ requires cxx11_variadic_templates cxx11_template_aliases cxx11_hdr_type_traits cxx11_hdr_tuple ] ;

6 16