April 2014 - Boost - lists.preview.boost.org

[atomic] Support for specialized instructions
by Andrey Semashev 14 May '14

14 May '14

Hi, I've been contemplating the idea of adding support for some specialized atomic instructions to Boost.Atomic. Since I'm only familiar with x86 architecture, my current candidates are: * Increment/decrement with a check for zero result (lock inc/dec). The decrement is the most essential of the two because it would be useful for reference counters of various kinds. The increment is mostly beneficial in terms of code size, and it probably doesn't need the check for zero in most cases. * In-place logical operations (lock and/or/xor). These are useful in cases when the code needs to operate on flags or bit sets but doesn't need the result of the operation. Optional variants can be provided with a test for zero result. * Bit set/reset operations (lock bts/btr). The use cases are similar to the logical operations but the advantage is that the previous value of the altered bit can be returned. BTW, these operations are needed in Boost.Sync to implement mutexes on Windows. All these operations can be implemented through the standard atomic<> interface, and that's what would be done on platforms without support for the specialized instructions. For now the idea is to add special member functions to atomic<>, when used with arithmetic types. I was thinking about providing free functions as well, although I think that the complete set of the standard atomic functions would be required for that. Comments? Opinions?

4 6

[graph] Fix for directed_graph::swap
by Ben Pope 14 May '14

14 May '14

https://github.com/boostorg/graph/pull/5 Ben

1 1

Re: [boost] [GSoC, MPL11] Community probe
by Louis Dionne 09 May '14

09 May '14

Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes: > I have a question: the proposal and library are called MPL11. That is true, but I'm starting to realize that it's a very bad name. The project started about two years ago, when C++14 was still out of my sight. Be reassured that I always consider the latest version of the language, not only C++11. > In my experience, relaxed constexpr allows for beautiful metaprogramming > with respect to C++11, in particular when combined with Boost.Fusion, and I > think that it is really a game changer with respect to C++11 constexpr, > since it allows not only "functional" metaprogramming but also "imperative" > metaprogramming, significantly lowering the learning curve of > metaprogramming for C++ programmers. Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations? See below for more on that. > Have you consider the influence of relaxed constexpr (C++14) in your > library? > > Could it simplify the design/implementation/usage of the MPL? I did consider the impact of C++14 on the design of the library, and I still am. At this point, my conclusion is that we must define what we mean by a "template metaprogramming library". I differentiate between two main kinds of computations that can be done at compile-time. The first is manipulating "pure types" with metafunctions (e.g. type traits): using void_pointer = std::add_pointer_t<void>; using pointers = mpl::transform< mpl::list<int, char, void, my_own_type>, mpl::quote<std::add_pointer> >::type; The above example is completely artificial but you get the point. The second kind of computation is manipulating values of a literal type at compile-time. using three = mpl::plus<mpl::int_<1>, mpl::int_<2>>::type; The MPL wraps these values into types so it can treat computations on those as computations of the first kind, but another library could perhaps handle them differently (probably using constexpr). constexpr int three = plus(1, 2); It is easy to see how constexpr (and relaxed constexpr) can make the second kind of computation easier to express, since that is exactly its purpose. However, it is much less clear how constexpr helps us with computations of the first kind. And by that I really mean that using constexpr in some way to perform those computations might be more cumbersome and less efficient than good old metafunctions. As for using constexpr to express computations on literal values, another question arises. Should there be a general library for handling those at compile-time, or should it be the responsibility of a well written domain- specific library to provide means to perform domain-specific computations at compile-time whenever possible? For example, should the MPL11 provide constexpr math functions, or should the std:: math functions be constexpr whenever possible? Another example is std::array. While the MPL11 could provide a constexpr container for homogeneous values of a literal type, simply changing the `begin` and `end` of `std::array` to be constexpr would make it possible to iterate on the array at compile-time. template <typename T, std::size_t n> constexpr T sum(std::array<T, n> array) { T s{0}; for (T i: array) // awesome s += i; return s; } constexpr std::array<int, 5> array{{1, 2, 3, 4, 5}}; static_assert(sum(array) == 15, ""); Unfortunately, I don't think this is happening in C++14, but I could be mistaken. Still, you certainly understand the implications. So a valid question that must be answered before I/we can come up with a "final" version of the library that can be proposed to Boost (or for standardization) is: "What is the purpose of a TMP library?" Once that is well defined, we won't be shooting at a moving target anymore. Right now, I have avoided these questions as much as possible by focusing on computations of the first kind. For those computations, my research so far shows that constexpr is unlikely to be of any help. If someone can come up with counter-examples or ideas that seem to refute this, _please_ let me know and I'll even buy you a beer in Aspen. This is _very_ important; it's central to my current work. > Would a rewrite of MPL11 be necessary afterwards (MPL14)? If constexpr turns out to be a game changer for computations of the first kind, then I suspect a large part of the current MPL11 would have to be rewritten. Of course, I tried to prevent this from happening by going slowly and looking at all the possibilities, but these things happen and it's part of the game. As for computations of the second kind, not _much_ work (comparatively) has been done on them because I knew it was a can of worms. So even drastic changes would not kill the library as it stands. Finally, if any of this does not make sense to someone, please let me know (on this list or privately) so I can explain further and correct any fallacious reasoning on my part. I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too. Regards, Louis

5 13

marking regression test failures as expected
by Andrzej Krzemienski 06 May '14

06 May '14

Hi, I noticed in the regression tests results taht some failing tests are marked as "fail*" in greyish color indicating that the failure is expected along with the explanation why. E.g., http://www.boost.org/development/tests/develop/developer/output/teeks99-03a… Question: how can I indicate that the new failure is expected in the same manner? Regards, &rzej

3 3

Anyone driving from/to Denver?
by Sebastian Redl 06 May '14

06 May '14

Hi, I could only get my bonus miles flights to Denver, not Aspen, so I'm wondering whether anyone else is only flying from/to Denver and driving the rest of the way. I would be interested in sharing that car. Please let me know. Sebastian

3 3

[GSoC, MPL11] Community probe
by Louis Dionne 04 May '14

04 May '14

Dear Boost, As a follow-up to [1], I am probing the community to help clarify what are your needs/expectations with respect to a new TMP library. Your involvement is important as it will help direct my work on an eventual successor to the MPL (in consultation with my mentor, Joel Falcou). I expect this to be the first of a series of probes to the community. This one focuses on backward compatibility with the MPL. COMMUNITY PROBE --------------- Please comment on how you would like to see the following points addressed by a new TMP library: (1) Backward compatibility with the MPL. Should it be a swap-in replacement? Is it enough to have an easy way to interoperate between both libraries (think Fusion/MPL interoperation)?. (2) Learning curve for users coming from the MPL. How important is it for you to be able to reuse your knowledge of the MPL (not of TMP, but of the MPL itself)?. Please get involved by posting constructive material. Regards, Louis Dionne PS: As I expect this to be the first of a couple of community-wide probes, is there a preferred way to do these (on the ML or elsewhere)? PPS: If the thread gets very active, I might be slow to answer. I'm spread between this and my finals. [1]: http://article.gmane.org/gmane.comp.lib.boost.devel/250424

8 21

[typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
by Niall Douglas 02 May '14

02 May '14

Dear Boost, A second round of community review begins for proposed Boost.TypeIndex on Mon 21st, lasting ten days. I should apologise as it's my fault for starting another peer review straight after Boost.Align ends, however I was busy as Google Summer of Code admin until today, and I will be preparing to talk at C++ Now straight after this review ends. I hope that this doesn't affect the community's willingness to contribute to the review. Reminder of the report from the last TypeIndex v2.1 review: https://groups.google.com/forum/#!topic/boost-list/TeiSdkRkUF0 Reminder of the original peer review announcement: http://boost.2283326.n4.nabble.com/TypeIndex-Peer-review-period-for-li brary-acceptance-begins-ending-Thurs-21st-Nov-td4654788.html Source code: https://github.com/apolukhin/type_index/zipball/master Github: https://github.com/apolukhin/type_index Documentation: http://apolukhin.github.com/type_index/index.html Changes in TypeIndex v3.0 since v2.1 (from my own review of it): 1. Documentation is hugely improved over v2.1, lots of side by side examples illustrating the differences and similarities. 2. You can now create your own custom type indices using an extensible framework. 3. boost::typeind::type_info now exports raw_name() and pretty_name() to maximise MSVC-GCC compatibility, and to solve point 1 but not point 2 in the v2.1 report. 4. The undefined behaviour trick used in v2.1 has been replaced with a cast via the placeholder type boost::typeind::detail::ctti_data which can be viewed in https://github.com/apolukhin/type_index/blob/master/include/boost/type _index/ctti_type_index.hpp. There is an explanation in the comments there about this technique's compatibility with the C++ standard. 5. TypeIndex now defines everything in the boost::typeind namespace instead of the boost namespace. So: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. 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. Thanks, Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

7 29

Spam in tickets
by Antony Polukhin 02 May '14

02 May '14

Hi, Could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/9963<https://svn.boost.org/trac/boost/ticket/7108> ? -- Best regards, Antony Polukhin

4 3

[graph] dijkstra algorithm object
by alex 30 Apr '14

30 Apr '14

Dear Jeremiah and Boost list, I'd like to suggest for inclusion in Boost Graph Library an algorithm object version of dijkstra shortest path algorithm. The following is an example how it can be used, assuming some graph, source node(s) and threshold distance: auto dijkstra make_dijkstra_object(graph, source_range); while(dijkstra()) { auto v = dijkstra.get_vertex(); auto distance_map = dijkstra.get<vertex_distance_t>(); if(get(distance_map, v) > threshold) break; } It is very close to what Jeremiah suggested 2 years ago: http://lists.boost.org/Archives/boost/2012/07/195300.php The main advantage for me is the possibility to interweave several shortest path searches. The algorithm object makes use of the stackless coroutine in Boost ASIO, which means it is relatively lightweight. However, on a large graph the algorithm object still takes about 20% more time than the normal dijkstra_shortest_path. The operator() progresses the algorithm to the next control point. Control points can correspond to all places where breadth_first_search invokes its visitor, but it is specified in compile time at which potential control points the algorithm actually yields. The default is to halt at the finish_vertex control point only. The make_dijkstra_object function can take all parameters through bgl_named_parameters, including the priority queue and the color map, which the existing dijkstra_shortest_path does not support. The code is part of the following project: http://code.google.com/p/resumable-dijkstra The algorithm object is defined here: http://code.google.com/p/resumable-dijkstra/source/browse/trunk/resumable-di jkstra/blink/graph/dijkstra_object.hpp I look forward to hear if there are any takers this time. Best wishes, Alex

1 0

[MPI] Fix can be merge to master
by Ben Pope 30 Apr '14

30 Apr '14

Please merge https://github.com/boostorg/mpi/commit/a7a2501242e78c65df9ff82c67dcad1f016b… to master. Should fix mpi and graph_parallel Ben

1 2