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

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

[build] b2 headers broken?
by Eric Niebler 02 Mar '15

02 Mar '15

I just updated to the latest develop. I ran bootstrap, then nuked my boost directory and reran b2 headers. Worked fine. Then I changed directory to libs/proto/test and ran ../../../b2 mem_ptr to run a test. Here's what I get: f:\modular-boost\libs\proto\test>..\..\..\b2 mem_ptr Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 4951 targets... ...updating 441 targets... common.mkdir ..\..\..\bin.v2\libs common.mkdir ..\..\..\bin.v2\libs\proto common.mkdir ..\..\..\bin.v2\libs\proto\test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0 common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static\threading-multi link.rm ..\..\..\boost\mpl common.mkdir ..\..\..\boost\mpl link.hardlink ..\..\..\boost\mpl\print.hpp Hardlink created for ..\..\..\boost\mpl\print.hpp <<===>> ..\..\mpl\include\boost\mpl\print.hpp <snip> link.rm ..\..\..\boost\numeric\conversion link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp The system cannot find the path specified. if exist "..\..\..\boost\numeric\conversion\conversion_traits.hpp" del "..\..\..\boost\numeric\conversion\conversion _traits.hpp" mklink /H "..\..\..\boost\numeric\conversion\conversion_traits.hpp" "..\..\numeric\conversion\include\boost\numeric\ conversion\conversion_traits.hpp" ...failed link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp... link.hardlink ..\..\..\boost\numeric\conversion\int_float_mixture_enum.hpp The system cannot find the path specified. For some reason, b2 thinks it needs to rerun b2 headers, but it does a crap job of it and dies. What's going on? Eric

4 6

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

file_descriptor::read() docs?
by Olaf van der Spek 19 Dec '14

19 Dec '14

Hi, Where is file_descriptor::read() documented? Shouldn't it be at http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/classes/file_descri… ? -- Olaf

2 3

File Handle and FILE* wrappers?
by Olaf van der Spek 16 Dec '14

16 Dec '14

Hi, Would there be any interest in wrappers for file handles / descriptors and FILE*? Sometimes one needs native handles or FILE* for interoperability or special features like memory mapped IO, but standard C++ doesn't provide convenient RAII friendly wrappers for these. The idea seems trivial yet quite useful. I'm aware of <boost/iostreams/device/file_descriptor.hpp> but it seems to be too high-level. I've put a simple start for FILE* at https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h What do you think? Also posted at https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Q4RdFSZg… -- Olaf

8 21

[utility] What happened to OptionalPointee/compare_pointees?
by Mostafa 16 Dec '14

16 Dec '14

1) OptionalPointee/compare_pointees reside here: libs/utility/OptionalPointee.html, but there's no way to navigate to it from here: libs/utility/ or here: libs/utility/utility.htm 2) IMO, compare_pointees should have stand alone documentation, and be grouped with pointee and indirect_reference. 3) pointee and indirect_reference are not iterator specific, therefore they shouldn't reside under iterator's documentation. IMO, compare_pointees, pointee and indirect_reference should all reside under a pointee utilities section. Thanks.

1 1

[safe_numerics] questioning the basic idea
by Andrzej Krzemienski 15 Dec '14

15 Dec '14

Hi, I was going through the Safe Numerics library in Boost Library Incubator, and I realized I disagree with the basic idea it is built on. I wanted to rise my concerns here. If I were to summarize in one sentence what this library is, I would say: a drop-in replacement for type int that checks for overflow in run-time and throws an exception if it finds one. Did I get it right? The remainder of this post is based on this interpretation. If so, I am not sure if this idea is a good one and worth promoting in Boost. BTW this is one of my criteria for letting a library into Boost: whether it promotes worthy ideas. I agree with the statement that a program should be UB-free. But I do not think that the approach of letting the programmer do what he did before, having the library or some run-time tool check for potential UB, and throwing an exception instead makes the program any better (or safer). It is just hiding the symptoms but not curing the disease. The programmer should not plant the UB in the first place - I agree. But this is different than first doing the mess and then having the run-time clean it up for you. I know it works for many people, in a number of languages, and it may even be considered a practical solution, but (by inclusion into Boost) I wouldn't like to be sending the message "this is how you are suppose to code". I try to recall how I use type int. I do not think I ever use it for anything that would be close to "numeric" as I know the term from math. Use Case 1 (an index): for (size_t i = 0, I = v.size(); i != I; ++i) { if (i != 0) str += ","; str += v[i]; } There doesn't appear to be a good reason to wrap it into safe<int> here, even though the incrementation could possibly overflow. Plus, it would kill my performance. Use Case 2 (using reasonably small range): I used an int to represent a square on a chessboard. There is only 64 squares, so I couldn't possibly overflow, on whatever platform. And even if there exists a platform where 64 doesn't fit into an int, I would not use safe<int> there. I would rather go for something like double_int. If I were to use some numeric computations on integers and I perceived any risk that I may overflow, I would not be satisfied with having the computations stop because of an exception. I would rather use a bigger type (BigInt?). I do not think int is even meant to be used in numerical computations. I believe it is supposed to be a building block for building more useful types like BigInt. One good usage example I can think of is this. After a while of trying to chase a bug I comae up with a hypothesis that my int could be overflowing. I temporarily replace it with safe<int> and put a break point in function overflow() to trap it and support my hypothesis. I would probably use a configurable typedef then: #ifndef NDEBUG typedef safe<int> int_t; #else typedef int int_t; #endif But is this the intent? But perhaps it is just my narrow perspective. Can you give me a real-life example where substituting safe<int> for int has merit and is not controversial? I do not mean the code, just a story. Regards, &rzej

6 12

List of C++ 11 only Boost libraries and their status?
by Niall Douglas 13 Dec '14

13 Dec '14

For C++ Now 2015 I am intending to present an overview of C++ 11 only Boost libraries in the review queue or very near the review queue by the time of the conference. I'd appreciate help filling in missing gaps in this list: * Boost.Spirit X3 ETA to Boost review: unknown, last commit was June 2014. * Boost.Proto 0x ETA to Boost review: unknown, last commit was Oct 2013. * Boost.Hana ETA to Boost review: Summer 2015, last commit was today. * Boost.AFIO ETA to Boost review: Already in review queue, last commit was two days ago. * Boost.BindLib ETA to Boost review: Q1 2015, last commit was two days ago. * Boost.Spinlock ETA to Boost review: Q2 2015, last commit was four days ago. * Boost.KernelAlloc ETA to Boost review: Q1 2015, last commit was today. * Boost.Expected ETA to Boost review: no later than Summer 2015 probably much earlier, last commit was two weeks ago. * Boost.CRUX ETA to Boost review: hopefully by end of 2015, last commit was three days ago. I have to admit surprise at how long the list I have collected already is. Are there any other C++ 11 only Boost libraries I am missing, or have I got the ETAs wrong? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

24 49

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[review] Last day for formal review for Sort library
by Edward Diener 12 Dec '14

12 Dec '14

Today is the last day for the formal review of the Sort library by Steven Ross, which started November 10. We have had some great discussions and reviews so far and I would like to thank everybody involved, but as always we need more formal reviews. If you need any delay for your review after today, please contact me at 'eldiener at tropicsoft dot com' and I will take your review into account if given within a reasonable period of time after today. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - 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. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 11

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

[optional] Safe optional
by Andrzej Krzemienski 28 Nov '14

28 Nov '14

Hi Everyone, I would like to run an idea through everyone in this list. There is a recurring complaint about Boost.Optional that it allows you to do "unsafe" things: 1. Inadvertent mixed comparisons between T and optional<T> 2. Unintended conversion from T to optional<T> 3. "Unchecked" access to the contained object, which causes an UB when performed on an uninitialized optional object. There are valid reasons why optional is defined the way it is defined. But at the same time the complaints above are also valid. This makes some people abandon Boost.Optional and use their own alternative. My idea is to provide another type wrapper, say safe_optional<T>, that would choose different tradeoffs: prefer "safety" to some flexibility and/or efficiency. It would probably be part of Boost.Optional library as the implementation can be reused - only the interface would be changed. One downside of this solution is that we would have two libraries for doing nearly the same thing, which could "scatter" the community. There is a value for standardizing certain things and making them universal. I would like to solicit your feedback. Regards, &rzej

18 84