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

Review request for Compute
by Antony Polukhin 10 Dec '14

10 Dec '14

Hi, Please add the the Compute library to the review schedule. Compute is a GPU/parallel-computing library for C++ based on OpenCL. Author: Kyle Lutz Source code: https://github.com/kylelutz/compute Documentation: http://kylelutz.github.io/compute/ Review Manager: Antony Polukhin Approximate review date: end of November - December 2014 -- Best regards, Antony Polukhin

2 2

Boost People section largely outdated
by Joaquin M Lopez Munoz 09 Dec '14

09 Dec '14

Hi, It is a pity that the Boost People section: http://www.boost.org/users/people.html is so outdated: many people there are no longer around, and, more importantly, many (most) current contributors are not listed. This is is a reminder for people to get themselves on that page! Instructions at http://www.boost.org/development/submissions.html#People Best Joaquín M López Muñoz Telefónica

3 2

[mpl] [build] [testing] Merge pull requests
by Andrey Semashev 08 Dec '14

08 Dec '14

Hi, There were a lot of discussions about MPL recently, and I created a few pull requests to address issues: https://github.com/boostorg/boost/pull/39 Invoke 'headers' target before building testing tools. Note that several testers are currently failing to run because of this problem. Since this affects the testing process, I'd appreciate if someone familiar with it could take a look. https://github.com/boostorg/boost/pull/38 Add MPL.Core tests to the test report. These tests are currently not run by testers. https://github.com/boostorg/mpl/pull/12 Move a misplaced header from MPL to MPL.Core to resolve circular dependency between the two. I believe the first PR is especially critical. Could someone with permissions merge these? Thanks.

13 52

Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
by Felix Uhl 05 Dec '14

05 Dec '14

David Stone wrote: >I have been bitten in the past by operator<. I was converting code that >used unsigned with a 'magic value' to represent nullness to >boost::optional<std::uint32_t>. However, the maximum value it used was >std::numeric_limits<std::uint32_t>:max(). A simple find and replace for >this magic constant (which was referred to everywhere as DWORD_NULL) with >boost::none and fixing compile errors led to some erroneous code. We had >code that assumed an 'uninitialized' std::uint32_t was greater than any >valid value. >The concept of "value not present" is not inherently less-than or >greater-than any value, but because of operator<, code compiled that >shouldn't have. I suppose this is really an argument against any operator< >overload, not just the mixed-type comparison. I don't expect this to be a >major problem for new code, but there is a lot of code out there that uses >a magic value, and that is what optional is supposed to replace. I was irritated by it at first, too, and if you think about it the comparison brakes down to a philosophical problem: If I have a pair of pants and you don’t, are my pants smaller than yours? Hard to say, but to me the most logical solution is “no”. My pants aren’t smaller than yours, and my pants aren’t larger than yours. Also, your and my logic would apply to both the operator<(optional<T>, T) and operator<(optional<T>, optional<T>), but I think we’re only talking about the latter. --- Felix Uhl

14 67

[review] [sort] Sort library review manager results
by Edward Diener 05 Dec '14

05 Dec '14

This is the results from the recent review of the Sort library of Steven Ross. First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes: Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg Dupuis Etienne, and Frank Gennari If I have missed anyone I do apologize. Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability. My tally of Yes and No votes for acceptance are: Yes votes (5) : Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ), Frank Gennari, Phil Endecott, Paul Bristow. No votes (3) : Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglass was almost completely met in the discussion with Steven Ross about the issues mentioned, and enough to maintain his Yes vote. I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations. Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager. 1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques. 2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions. Steven Ross has been providing these charts/tables in the 'develop' branch of the library. 3) Connected to the previous issue is that a number of reviewers asked for better documentation on the conditions in which SpreadSort will show a marked improvement in speed compared to std::sort, as well as any condition(s) where SpreadSort performs worse than std::sort. While Steven Ross has explained that generally SpreadSort will fall back to using std::sort for some cases ( low N ), I too feel that the documentation needs to be more extensive for the average user in attempting to delineate the conditions where SpreadSort works best. 4) A really important issue discussed by a number of reviewers involves the creation of a synthetic radix, where most users of sorting algorithm are used to comparison based sorting functors. While the documentation provides information on the various individual sorts, as well as examples, I also feel that a discussion in the documentation of how to use SpreadSort when sorting structs/classes with multiple keys of different types would be invaluable. In other words, what and if are the common techniques for using SpreadSort with complicated keys which, when using comparison-based sorting, can be represented fairly easily be a functor. 5) Niall Douglass brought up the issue of exception guarantees when using SpreadSort, and I concur. The documentation should be stronger specifying what happens during the sorting algorithms if an exception occurs and/or does the sorting algorithm itself ever throw any exceptions and, if so, under what conditions. Steven Ross mentioned that he is adding exception guarantee information to his docs. 6) Many reviewers did not like the idea that the library should be called Sort when it is basically implementing a single sorting algorithm called SpreadSort. Alternate suggestions are: a) The library should be called SpreadSort. b) The library can be called Sort only if other sorting algorithms are added to it. c) The library can be called Sort with the proviso that it serves as a general library for sorting algorithms potentially added to it in the future. d) The library should be part of the Boost Algorithm library. Steven Ross mentioned other potential sorting implementations as part of the Sort library, under that general name, but all providing a good deal of extra work. These included a copy-based stable sorting algorithm, an LSD radix sorting, and an OpenMP based parallel implementation. Other reviewers mentioned some of the same types of sorting implementations and a few reviewers remarked that they also have created sorting implementations of their own. While I will give my own view at the end, I would like to mention here that I strongly believe that each sorting implementation needs to be reviewed separately for acceptance into Boost and never automatically added to a general library, whether it be called Sort or Algorithm or whatever. 7) Random issues brought up in comments I will mention, which have importance but which I do not believe are absolutely intrinsic yet still might be considered. a) C++11 techniques in general and inline namespaces in particular. b) A version that can work with less than random access. c) Optimizations for small sets of data ( Steven Ross has already addressed this to an extent in the 'developer' branch of the library ). d) Possible documentation of using SpreadSort as a subsort for parallel sorting techniques and possible discusion in the docs about Spreadort and parallel sorts. e) General O() information in docs. f) SpreadSort examples hoisted directly into docs using Quickbook technique and updating the Spreadort docs to use Quickbook. Review Result: Based on the voting for acceptance or not, based on the discussions during the review period, and based on Steven Ross's responses, I have decided that Steven Ross's library should be accepted into Boost. My main reason for my decision, aside from the votes and comments and specific issues discussed, is twofold: 1) There is a general consensus that Steven Ross has an excellent understanding of sorting techniques and algorithms and will support and refine his library for the benefit of programmers. 2) The empirical tests show that SpreadSort offers an improvement over std::sort, significantly in the area of large data sets, and this could be a major benefit to programmers. I do not know if the review manager has a say in this but based on the remarks of the reviewers I would like to see the library as accepted be named 'SpreadSort' rather than just 'Sort'. I do think that Boost can have a library called 'Sort' but I agree with the general consensus that a 'Sort' library needs more than one type of sorting algorithm. I would like to see other people, who mentioned in the reviews/comments that they have their own sorting implementation, also submit their own implementations to Boost and, if this happens and they are accepted, I can see combining them with 'SpreadSort' into a general Boost sorting library called 'Sort' in the future.

10 26

[VC++ 14.0 preview] New failures in develop regression tests
by Beman Dawes 03 Dec '14

03 Dec '14

At my request, Tom Kent has kindly added VC++ 14.0 (toolset msvc-14.0) to his develop branch tests. See http://www.boost.org/development/tests/develop/developer/summary.html rightmost column. This compiler is available as part of the Visual Studio 2015 Preview. See http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs… Several libraries are showing new test failures. Please check out the test results to see if your library has started to fail. If it is your problem, fix it or at least create a ticket for yourself:-) If it is a Microsoft problem, consider submitting a bug report and posting a notice on the Boost list so that other developers are aware of the problem. Also post a link to the bug report on https://connect.microsoft.com Knowing the Microsoft Connect URL for the bug report lets other boosters up vote the importance of the issue. This is known to have at least some influence on the priority given the bug report, and that means faster fixes for the bugs boosters care about. Thanks, --Beman

6 9

GDB-like debugger for template metaprograms
by Abel Sinkovics 03 Dec '14

03 Dec '14

Hi, Metashell 2.0.0 has a template metaprogram debugger with a GDB-like interface (thanks to András Kucsma), which can be useful for Boost developers. It can show you how your metaprogram is executed step-by-step. You can set breakpoints, step into or over the metafunction calls and inspect the "template metaprogramming stack trace" at any point during this: the chain of recursive template instantiations that lead to that point. Here is an example: > #include <boost/mpl/transform.hpp> > #include <boost/mpl/vector_c.hpp> > #include <boost/mpl/plus.hpp> > #include <boost/mpl/lambda.hpp> > #include <boost/mpl/int.hpp> > using namespace boost::mpl; > #msh mdb transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type For help, type "help". Metaprogram started (mdb) rbreak ^boost::mpl::plus Breakpoint "^boost::mpl::plus" will stop the execution on 25 locations (mdb) continue Breakpoint "^boost::mpl::plus" reached boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) (mdb) bt #0 boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (Memoization) #1 boost::mpl::quote_impl<boost::mpl::plus<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na>, true> (TemplateInstantiation) #2 boost::mpl::quote5<plus, mpl_::void_>::apply<mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) #3 boost::mpl::apply_wrap5<boost::mpl::quote5<plus, mpl_::void_>, mpl_::integral_c<int, 1>, mpl_::int_<1>, mpl_::na, mpl_::na, mpl_::na> (TemplateInstantiation) ... #19 transform<vector_c<int, 1, 2, 3, 4, 5>, plus<_1, int_<1>>>::type You can try Metashell from your browser: http://abel.web.elte.hu/shell Or you can install it on your computer: https://github.com/sabel83/metashell#version-200 Binary installers are available for a number of Linux distributions, Windows and Mac OS X. Feedback is welcome. Regards, Ábel

7 15

boost::async documentation
by Aaron Levy 29 Nov '14

29 Nov '14

I did not see any explicit documentation of the boost::async template although I see some mention of it since Boost 1.53. Is there some cohesive documentation which lists: 1. The macros needed to enable the functionality if any. 2. Details of behavior and limitations. 3. Differences in behavior wrt std::async. -- Aaron Levy aaron.levy(a)yandex.com

2 1

boost.context cause strange crash on certan WIN32 API
by microcai 29 Nov '14

29 Nov '14

Hi, I was using Boost.Asio.Spawn happliy until I ported my project to windows. I got stange openssl crash. many debug days speeded and there was nothing wrong with openssl. Strange thing is, openssl didn't crash when used in normal code, unless I used them in asio stackful coroutine. Now I finnally find the root cause and make it 100% reproducible. here is the code that demostrade the crash: <code> boost::context::fcontext_t fcm,fc1; void f1(intptr_t) { HMODULE advapi = LoadLibrary(TEXT("advapi32")); // crash there FreeLibrary(advapi); boost::context::jump_fcontext(fc1, &fcm, 0); } std::thread([](){ boost::context::guarded_stack_allocator alloc; std::size_t size(8192); void* sp1(std::malloc(size)); fc1=boost::context::make_fcontext(sp1, size, f1); boost::context::jump_fcontext(&fcm, fc1, 0); }); </code> the context created in threads other that main thread, can't call certain APIs. If LoadLibrary get called by an context that created in thread, it will crash. 100% reproducible on WIN64 platform with MSVC2013. And nothing wrong on WIN32 !

2 2

[Boost.Convert] Specify input using iterators
by Marius Dobrea 28 Nov '14

28 Nov '14

Hi Vladimir, While reading the Boost.Convert documentation last night there were some questions which came to my mind: Have you considered using iterators (or ranges) to specify input? Would that be in the scope of your library? Also I note that the strtol() function returns the position of the first invalid character (endptr below): long int strtol (const char* str, char** endptr, int base); Could convert() provide the position where the conversion stopped? This would allow single pass parsing of some input data. Would a Converter callable with the following signature be useful? template<typename TypeOut, typename InputIterator> class Result { public: enum Errc { numeric_overflow, empty_range, invalid_character, ...}; // std::expected like function signatures here private: TypeOut value; int errors; InputIterator pos; }; template<typename TypeOut, typename InputIterator> void operator()(InputIterator begin, InputIterator end, Result<TypeOut, InputIterator>& result) const; Please let me know your thoughts. Thanks, Marius Dobrea

2 1