June 2015 - Boost - lists.boost.org

comparing test results between master and develop
by Stefan Seefeld 26 Jun '15

26 Jun '15

Hello, I'm trying to compare the state of the develop and master branch for the Boost.Python project, to figure out whether I can merge the develop branch to master. I find that a bit difficult, though, and was wondering whether people here have any advice. Are there any tools to generate an easy-to-analyze diff ? Right now I'm visually inspecting http://www.boost.org/development/tests/master/developer/python.html and http://www.boost.org/development/tests/develop/developer/python.html, which in itself is non-trivial given the size of the table. In addition, some testers only run on develop, some only on master, creating incommensurable results. Is there a better way to do this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

[build] msvc-14.0 toolset can't find mt.exe?
by Peter Dimov 26 Jun '15

26 Jun '15

I've installed Visual Studio 2015 RC Community, and the msvc-14.0 toolset can't find mt.exe. I have mt.exe (twice), once in the 7.1A SDK, once in the 8.1 SDK. Does anyone have an idea what's wrong?

2 1

[hana]recursive data type?
by Larry Evans 25 Jun '15

25 Jun '15

How would one define a recursive data type in hana something described by the type equation: hana_list<T> = hana::nothing | std::pair<T,hana_list<T> > where hana_list<T> is a list of T's terminated by nothing?

2 2

future/packaged_task Sean Parent design
by Vicente J. Botet Escriba 25 Jun '15

25 Jun '15

Hi, Sean Parent suggests (See [1] Better Code: Concurrency) to remove the promise and left the packaged_task serve as single provider of a future. Both are created at once using the package factory. His future library doesn't include a shared_future as the future contains a value that can be observed several times. The continuation takes the value and not the future. So a future can have several continuations. If the store type is movable only, then the future can have only one continuation. Not really strange coming from Sean, future and packaged_task are copyables :) One more thing, there is not get no wait, but a get_try that return an optional<T>. Scales better. IIUC the implementation allows to implement when_all on top of future/packaged_task. The trick is that that the packaged_task can store some context. async has always an Scheduler as parameter. Scheculers are just Copyable Callables having this signature void(void()). There is no need for function add/spawn. when_all has also a callable as argument. I find the Sean's design clean and simple (See the code [2]). What do you think of it? Do you see any issues on it? * I don't understand why when_all continuation has the futures as parameters (I suspect that this is a type on the documentation). * I would rename get_try to try_get. This function could return optional<expected<T>>. What are you missing ? * catch_error/recover that is already planed. * when_any Best, Vicente [1] https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presen… [2] https://github.com/stlab/libraries/tree/develop

3 5

Using Clang compiler in place of GCC
by Paul A. Bristow 25 Jun '15

25 Jun '15

I have installed Clang 3.6.1 (along with previously used versions of GCC) downloaded from LLVM and using the clang for LLVM Windows installer on Windows 8.1 I:\modular-boost\libs\fixed_point\example>clang++ --version clang version 3.6.1 (tags/RELEASE_361/final) Target: i686-pc-windows-gnu Thread model: posix suggests that I have the compiler in place OK and it should be in my PATH (becos I asked for it to be). --debug-configuration notice: will use 'C:/LLVM/bin/clang++.exe' for clang-linux, condition <toolset>clang-linux-3.6.1 For a project, I have a jamfile starting project : requirements <include>../include # quickdox/include <include>../../.. # modular-boost root #toolset requirements. # GCC requirements. #<toolset>gcc:<cxxflags>-std=gnu++11 # If requires C++11 library. <toolset>gcc:<cxxflags>-Wno-unused-local-typedefs <toolset>gcc:<cxxflags>-Wno-missing-braces # Clang requirements. #<toolset>clang:<cxxflags>-std=c++11 # If requires C++11 library. (I also have environment BOOST_ROOT = I:\modular-boost) when I run b2 toolset=gcc all compiles and run as expected. when I run b2 toolset=clang I get messages like common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1 common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.6.1\debug clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\ clang-linux-3.6.1\debug\quick_auto_dox_index.obj quick_auto_dox_index.cpp:53:10: fatal error: 'iostream' file not found (or other files like cstddef, iomanip on other projects) #include <iostream> ^ 1 error generated. "C:/LLVM/bin/clang++.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32 -DBOOST_ALL_NO_L IB=1 -I"..\..\.." -I"..\include" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test \clang-linux-3.6.1\debug\quick_auto_dox_index.obj" "quick_auto_dox_index.cpp" (Full log attached). This suggests that it is not finding the system file <iostream> ... but I'm puzzled at what is missing (and why). Suggestions most welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 11

Stupid Constexpr Lambda Trick
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

Hi All, In the last few months constexpr lambdas and their absence in the standard came up multiple times in boost-devel, expecially when discussing the Hana library. I just wanted to share a C++14 emulation of the feature. The emulation uses both the already known conditional operator trick to allow constepr function objects to be initialized from lambda expressions, plus what I think is a novel trick to allow the actual function object operator() to be constexpr. Implementation + example is here: https://github.com/gpderetta/libtask/blob/master/lambda.cpp Sorry about the macro obfuscation, I was experimenting with a 'cute' lambda interface, but the underlying idea is very simple and pretty obvious in retrospect. I haven't tested that forwarding is always correc and I probably got some cases wrong. Lambda captures and multiple statemens are doable, but are left as an exercise for the reader :) I came up with the trick when trying to implement an emulation of N3617 (Lifting overload sets into function objects). Turns out that implementing the 'quote' syntax is almost trivial in C++14 with generic lambdas, but making it constexpr reliably has so far eluded me as all implementations I have tried ICE both gcc and clang. Still the constexpr lambda emulation itself seems to work. HTH, -- gpd

2 2

Re: [boost] future/packaged_task Sean Parent designn
by Giovanni Piero Deretta 24 Jun '15

24 Jun '15

On 24 Jun 2015 10:11 am, "Niall Douglas" <s_sourceforge(a)nedprod.com> wrote: > > On 24 Jun 2015 at 1:09, Vicente J. Botet Escriba wrote: > > > Sean Parent suggests (See [1] Better Code: Concurrency) to remove the > > promise and left the packaged_task serve as single provider of a future. > > Both are created at once using the package factory. > > I was at his talk at C++ Now. > > The first thing which put me off his proposal was that he appears to > be unaware of the highly optimised and very flexible de facto task > concurrency system in C++ which has been around for years, and has > just recently been standardised. It's called ASIO. > > I also think packaged_task is overkill for creating futures. There > are some times you really do just want a promise and nothing more. There is no reason for a packaged task implementation to be more heavy weight than a promise. If the packaged task is [](T x) { return x; } then it is also semantically equivalent to promise<T>, just in a nicer interface. Bonus points it works beautifully with ASIO without any explicit support from ASIO itself. > There are even times you just want to create a future standalone, and > for that we now have make_ready_future(). > > > His future library doesn't include a shared_future as the future > > contains a value that can be observed several times. > > If I remember rightly, internally his future has a shared_ptr, which > really means he's proposing that future becomes a shared_future. I > had doubts before until that part, but that killed his proposal for > me. It's a non-starter as a practical design for my needs, but is > still useful for ideas. > His implementation uses a shared ptr, but I think you could do without by deep copying the futures and internally chaining via then. This way you only pay the cost if you actually copy. I strongly believe that 'then' and other accessors should be non const so that concurrent calls *on the same future* need not be supported. -- gpd

3 4

[hana] Formal review
by Christophe Henry 24 Jun '15

24 Jun '15

Dear all, Following is my review of Hana. - Whether you believe the library should be accepted into Boost Yes, unconditionally. Having only one compiler compiling it is not the library's fault and it should not be held against it. If possible, I'd like to have some gcc support (and a clear note of what can be used with gcc). - Your name Christophe Henry - Your knowledge of the problem domain. Good knowledge of TMP, MPL and Fusion through my authoring of MSM. No expert of C++14 - What is your evaluation of the library's: * Design Very nice and interesting. What really slapped me in the face is writing this: template <typename ...T> auto smallest = minimum(make_tuple(type<T>...), [](auto t, auto u) { return sizeof_(t) < sizeof_(u); }); Instead of with MPL: template <typename ...T> struct smallest : deref< typename min_element< vector<T...>, less<sizeof_<_1>, sizeof_<_2>> >::type > { }; Ouch! I had forgotten how hard MPL can be... However, being value-based instead of type-based turns out to be a strength but also a weakness. To test the library, I replaced some simple MPL-based implementation parts of MSM with Hana. It works, but the code is not as simple and clean as I had hoped. For example: typedef typename ::boost::mpl::fold< stt_simulated,mpl::vector0<>, ::boost::mpl::push_back< ::boost::mpl::placeholders::_1, make_row_tag< ::boost::mpl::placeholders::_2 , BaseType > > >::type type; Became: static auto fold() { return boost::hana::fold.left(stt_simulated{}, boost::mpl::vector0<>{}, [](auto vec, auto t) { return typename ::boost::mpl::push_back< decltype(vec), typename make_row_tag <typename decltype(t)::type, BaseType>::type>::type{}; }); } typedef decltype(fold()) type; I had to create object where I actually just wanted types and also a static function so I can decltype. This is because this code was written within a struct (serving as metafunction). Honestly, my win in readability is limited ;-) But my problems started earlier. The heart of MSM is the transition table: struct transition_table : mpl::vector< Row < Stopped , stop , Stopped , none , none >, ... >{} All states and events being types, using Hana would lead me to write: Row < Stopped{} , stop{} , Stopped{} , none{} , none{} > which would be a regression. I'd love to get rid of my mpl::vector but Hana won't help me there. Maybe MSM was the wrong test object. The lack of support for mpl::set reduces to a very small part the algorithms I could port to Hana. Louis seems to want to change this, which I can only welcome. In the end, I feel that using Hana with MSM would be a take all or nothing choice. With the current compiler support, it is not something I will do in the next few months. Still, the library has a nice design and potential and I will probably use it either later in other use cases (or with MSM with better support of MPL). * Implementation I had a short glance and found it very clean. I found only one thing which bugged me, the use of non fully qualified names in some places. True, many other boost libraries do the same and it brings a lot of problems (anyone who tried to include Geometry and TypeErasure in one TU will love the duplicate definition of use_default). Still, a "return true_;" is begging for conflicts. * Documentation Great! Way above Boost level. As others said, please use fully qualified names where possible. It makes it much easier to follow. * Tests Did not look. * Usefulness Very useful if you have objects in the first place, maybe less to do TMP. - Did you attempt to use the library? If so: * Which compiler(s)? Clang 3.5. * What was the experience? Any problems? I got a few compiler errors. - A static_assert "hana::fold.left(xs, state, f) requires xs to be Foldable" when forgetting to #include <boost/hana/ext/boost/mpl/vector.hpp> I had included boost/hana.hpp but it did not include all, which is annoying. - a name conflict with std::size_t, though I deserved punishment by adding a using namespace boost::hana before including other headers. - How much effort did you put into your evaluation of the review? 8 hours reading the doc and rewriting some MSM algorithms with Hana. Thank you Louis for writing this excellent library and thank you Glen for managing the review! Christophe

2 1

[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