March 2016 - 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

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

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

[MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra

12 48

[config] RFC PR 82
by Domagoj Saric 01 Aug '16

01 Aug '16

Hi everyone, I am finally getting back to (trying to) contributing some of my personal projects to Boost. For two of those, Err (https://github.com/psiha/err) and especially Functonoid (a C++11 generalization and rewrite of my previous Boost.Function related work) I need some lower level codegen and/or optimiser control functionality (i.e. portable macros wrapping toolset specific attributes and pragmas) that I've added to my personal fork of Boost.Config and which I've now submitted in the subject PR (https://github.com/boostorg/config/pull/82) I don't expect this PR to be accepted as is/'just like that' so I'm opening this thread where we can discuss which of those changes/macros are welcome, which need more work and which, for some reason, should not be part of Boost.Config (and which, in turn then, I have to move to some 'internal implementation headers' in libraries that will need them). To avoid 'spamming' (and save time;) I'll skip the explanation of the individual macros as I expect them to mostly be self-explanatory (if not from their name then from the minimal Boost.Config documentation additions that are part of th PR). ps. I'll be on the (off) road for the next three weeks so I don't know when I'll be able to respond until I get back... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

8 31

[clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
by Edward Diener 07 Apr '16

07 Apr '16

I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++. I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation. I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like: using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14 By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code. There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests. I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard. I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.

8 31

Nasty compile time reflection and iteration for POD types using C++14 without macro
by Antony Polukhin 07 Apr '16

07 Apr '16

Hello, I've come up with a trick that may be useful in Boost.Hana, Boost.Serialization or some other libraries. Here's a small motivating example: #include <cstdio> #include <boost/type_index.hpp> #include "magic.hpp" struct foo { unsigned char i0; unsigned int i1; unsigned short i2; unsigned long long i3; unsigned char ar[2]; int q; std::size_t w; int* p1; const void* p2; int const**const**** p_crazy; const double d; }; template <std::size_t I, class T> void print(T& f) { printf( "%lu\t\t%s\n", (std::size_t)get(f), boost::typeindex::type_id<decltype(get(f))>().pretty_name().c_str() ); } int main() { foo f {10, 11, 12, 13, {14, 15}, 16, 17, 0, 0, 0, 30.0}; print<0>(f); print<1>(f); print<2>(f); print<3>(f); print<4>(f); print<5>(f); print<6>(f); print<7>(f); print<8>(f); print<9>(f); print<10>(f); print<11>(f); static_assert(tuple_size<foo>() == 12, "failed tuple size check"); } That example will output: 10 unsigned char 11 unsigned int 12 unsigned short 13 unsigned long long 14 unsigned char 15 unsigned char 16 int 17 unsigned long 0 int* 0 void const* 0 int const** const**** 30 double Core ideas: 1) We may detect the POD structure fields by the POD's constructor: template <std::size_t I> struct ubiq { std::size_t* ref_; template <class Type> constexpr operator Type() const noexcept { ref_[I] = type_to_id(identity<Type>{}); return Type{}; } }; template <class T, std::size_t... I> constexpr auto type_to_array_of_type_ids(std::size_t* types) noexcept -> decltype(T{ ubiq{types}... }) { return T{ ubiq{types}... }; } Here type_to_array_of_type_ids will return array with types via `types`, each element of array encodes some basic type. 2) Then we convert that array into an std::index_sequence<I...> and create a type with same layout as our POD type: template <std::size_t... I> constexpr auto as_tuple_impl(std::index_sequence<I...>) noexcept { return std::tuple< decltype( id_to_type(std::integral_constant<std::size_t, I>{}) )... >{}; } 3) Now we have a type with same layout, and we cast the structure to that type: template <std::size_t I, class T> decltype(auto) get(const T& val) noexcept { auto t = reinterpret_cast<const decltype(detail::as_tuple<T>())*>( std::addressof(val) ); return get(*t); } Drawbacks: * works for POD types only (could be possibly extended to trivial constructible type) * structures with non-default alignment are not supported * step 3) contains an UB, but even without that step we're still able to get field types of the POD type and fields count * current draft implementation does no support nested PODs (could be fixed easily) * current draft implementation works only on libc++ (could be fixed easily, requires reimplementing std::tuple) * there's no known to me way to make get<>() method constexpr * does not detect constness (because of that get<>() always returns const reference) Is there any interest in this feature? Sources https://github.com/apolukhin/magic_get/blob/master/magic2.cpp Online experiments can be done here: http://coliru.stacked-crooked.com/a/c33857e566e76ce2 -- Best regards, Antony Polukhin

8 15

Boost 1.61.0 Beta 1
by Vladimir Prus 06 Apr '16

06 Apr '16

The first beta packages for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1.zip http://boost.cowic.de/rc/boost_1_61_0_b1.7z http://boost.cowic.de/rc/boost_1_61_0_b1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1.tar.gz There are no changes compared to RC2, expect for different names of the archives and different name of the top-level directory in the archives. The SHA256 checksums are as follows: 3f8888099ee6f62b412a13be916dead2bacbdd6d69e5afd5b6fea4bb738e5df4 boost_1_61_0_b1.7z 866941f0038b27fcc69ced1490b2dc5fa8d20f505d66b939a92a68ef194d1a6c boost_1_61_0_b1.tar.bz2 0b92c5fb5b91641409b9675b2fd11d3b3fa5f71dd986d3b5fb03da201bf55474 boost_1_61_0_b1.tar.gz 9dffe5ee7f5f7bf7695f5738c686e44bd266933e3ca68732b0de5520c3c82615 boost_1_61_0_b1.zip Signed list of checksums should be posted within 24 hours. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. It was discovered that the .zip and .7z archives actually have LF line endings, at least in some places. Fixing this is not quite trivial, as Travis uses ancient version of Ubuntu and Git, and is not deemed critical, as most Windows editors handle LF just fine. We might do something for the final release, or might not. Thanks! -- The release managers

6 14

[build] How to use with clang on windows?
by John Maddock 03 Apr '16

03 Apr '16

What's the correct way to configure clang on windows with current Boost.Build? If I use: using clang-win : 3.7 : "C:/Progra~2/MICROS~4.0/VC/Clang 3.7/bin/x86/clang.exe" : <cxxflags>-std=c++11 <compatibility>vc14 ; to configure the clang that ships with VC14 I see: compile-c-c++ ..\..\..\bin.v2\libs\smart_ptr\test\shared_ptr_basic_test.test\clang-vc14-win-3.7\debug\shared_ptr_basic_test.obj clang.exe: error: no such file or directory: '/Od' clang.exe: error: no such file or directory: '/Ob0' clang.exe: error: no such file or directory: '/W3' clang.exe: error: no such file or directory: '/GR' clang.exe: error: no such file or directory: '/MDd' clang.exe: error: no such file or directory: '/Zc:forScope' clang.exe: error: no such file or directory: '/Zc:wchar_t' clang.exe: error: no such file or directory: '/wd4675' clang.exe: error: no such file or directory: '/EHs' Same errors with the llvm clang-3.9. On the other hand if I initialize with: using clang : : "C:/Progra~2/LLVM/bin/clang.exe" : <cxxflags>-std=c++14 <compatibility>vc14 <cxxflags>-fms-compatibility-version=19.00.22609 ; Then this sort of works for llvm clang, but not the msvc one (can't find c2.exe), but the compiler is identified as "clang-linux" and I see: LINK : warning LNK4044: unrecognized option '/-start-group'; ignored LINK : warning LNK4044: unrecognized option '/Bstatic'; ignored LINK : warning LNK4044: unrecognized option '/Bdynamic'; ignored LINK : warning LNK4044: unrecognized option '/-end-group'; ignored Plus some linker errors such as: yield_k_test.obj : error LNK2019: unresolved external symbol __mm_pause referenced in function "void __cdecl boost::detail::yield(unsigned int)" (?yield@detail@boost@@YAXI@Z) Ideas? Thanks, John.

7 29

Boost 1.61.0 open for fixes
by Vladimir Prus 02 Apr '16

02 Apr '16

The master branch is now open for bugfixes for 1.61.0. Please make sure that develop tests are healthy prior to merging. We're two weeks late relative to the plan, so further dates were also moved by two weeks in the calendar. -- The release managers

2 1

[Trac][convert] Associate Vladimir as author of Boost.Convert
by Vicente J. Botet Escriba 01 Apr '16

01 Apr '16

Hi, I requested sometime ago to add convert to the Trac system. It was done, but it was associated to me as maintainer. Please, could someone assign it to Vladimir Batov Vladimir, I guess you need to give your use in name. Best, Vicente Convert <http://www.boost.org/doc/libs/1_60_0/libs/convert/> An extendible and configurable type-conversion framework. Author(s) Vladimir Batov First Release 1.59.0

4 5

Coroutine2 examples - Cannot link properly.
by Carlos Ferreira 01 Apr '16

01 Apr '16

Hello to all. I'm having trouble in compiling the coroutine2 examples. For the fibonacci example, the following linking error occurs: /usr/include/boost/coroutine2/detail/pull_control_block.ipp:62: undefined reference to `boost::context::execution_context::current()' Now, I know that I have to link against boost context, something that I'm already doing, but for some reason, it is not enough. Can anyone help me with this? Thank you. -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

3 14

[boost 1.61] authorization to merge to master
by Raffi Enficiaud 31 Mar '16

31 Mar '16

Dear Boost, I would like to merge a boost.test bugfix to master. Those changes are running on develop for a week. I haven't done my PR for the website change log update because of that (would change the content of the PR). According to the schedule, boost 1.61 is open for bugfixes since 10 days now, but as I understood, we are still waiting for post RC2 go. - do I still have time for the website PR? - would the opening 1.61 for bugfixes be announced on the ML? - Am I allowed to merge those changes, so that I can reopen develop for post 1.61 developments? Thanks, Raffi Enficiaud

2 2

[boost 1.61 - [thread] Request for permission to merge
by Vicente J. Botet Escriba 31 Mar '16

31 Mar '16

Hi, I would like to merge once it is announced that the release branch is open for fixes a minor fix https://svn.boost.org/trac/boost/ticket/11562 - (condition_variable_any::wait_until + recursive_mutex + steady_clock) timer expires after computer time is set forward on Ubuntu 64-bit add missing template parameter in wait_until. https://github.com/boostorg/thread/commit/9db70b803d8f45632cd92cd61ab019c1f… and the rollback of something that resulted in a regression https://svn.boost.org/trac/boost/ticket/12049 - Assertion failure from detached threads during shutdown rollback BOOST_THREAD_PATCH. https://github.com/boostorg/thread/commit/47357de276fe4fc01469f34c1dbf8b26f… Best, Vicente

1 1

Re: [boost] [filesystem] Horrible documentation
by Tatsuyuki Ishi 31 Mar '16

31 Mar '16

> From: Edward Diener <eldiener(a)tropicsoft.com> > Date: Wed, 30 Mar 2016 00:06:00 -0400 > Subject: Re: [boost] [filesystem] Horrible documentation > > What sort of documentation unification with other libraries do you mean ? By saying unification, I'm talking about the green-background header. It's in most documentation and also on the homepage. > Can you not increase the font size, if it is too small for you to read, in your preferred browser since the doc is HTML ? The layout is quite problematic. Not only the font, text breaks border, and the page is too tall(long). I noticed it's created with FrontPage 2002. Come on, this is 2016.

3 2

[release] Download data
by Daniel James 31 Mar '16

31 Mar '16

Hi, Currently the download details for a release are included in the quickbook source file for the release notes, which is a bit wonky, and makes it tricky to add extra data, so I'm thinking about storing it separately. This should make it easier to add things like hash signatures and links to third party downloads, such as the windows binaries. So I'm thinking about how to make it easy for people to add the details of their downloads. Could possibly create an extra file for each release, and then people can add data using pull requests, much as we've been using pull requests on the quickbook files, which seems to work fairly well. Another possibility is that we could pull in the details from the server's API, although I don't really fancy having to support multiple data sources with different APIs. Any other ideas? Also, is there any way in which you'd like me to make this kinds of information available for your scripts, packaging etc. Here's a rough version of how the internal data might be stored in a JSON file (other file formats are possible): { 'version': '1.61.0', 'status': 'beta', 'release-notes': '/feed/history/boost_1_61_0.qbk', 'documentation': '/doc/libs/1_61_0/', 'downloads': [ { 'url': 'http://..../boost_1_61_0_beta1.tar.bz2', 'hash': '484c635.....' }, { 'url': 'http://..../boost_1_61_0_beta1.7z', 'hash': 'f93de8.....' }, // ... ], 'third-party': [ { 'url': 'http://...', 'title': 'Windows binaries', 'whatever_else': '' } ] }

1 0

[filesystem] Horrible documentation
by Tatsuyuki Ishi 30 Mar '16

30 Mar '16

Sorry for complaining. Is there any plan to use any documentation tool to regenerate this? It's not unified with other libraries, and too horrible due to the small font size. I really can't read that.

2 1

[Root Pointer] Benchmark w/ Threading = 124% faster
by Phil Bouchard 30 Mar '16

30 Mar '16

I just noticed that if I do not define the BOOST_DISABLE_THREADS macro, root_ptr is faster than allocate_shared_noinit by 124%: unique_ptr (new): 42.1397 unique_ptr (make_unique): 43.4631 shared_ptr (new): 76.4543 shared_ptr (make_shared): 76.6611 shared_ptr (allocate_shared_noinit): 81.9926 root_ptr (new): 66.3417 Thanks, -Phil

1 2

Fwd: [sort parallel] New Parallel Sort Algorithm
by Francisco José Tapia 29 Mar '16

29 Mar '16

This message is for to announce the new version of the Boost Sort Parallel algorithms. You can find in http://github.com/fjtapia/sort_parallel. In the documentation, you can see the description of the algorithms, examples of invocations, and the graphs of the benchmark of the algorithms. The benchmark was not include in the library. I created other repository https://github.com/fjtapia/sort_parallel_benchmark, where you can find the code of the benchmark, the library, and the external code of the TBB parallel stable sort. It was not logic, include external code inside the library. The most significant of this version is the new parallel sort algorithm (internally named Block Indirect Sort) In the Parallel Sort Algorithms, we can find two groups. - Algorithms very fast with many threads (GCC Parallel Sort, Microsoft Parallel Buffered Sort), but use an additional memory as the data. - Algorithms without additional memory, but slower with many threads (TBB Parallel Sort, Microsoft Parallel Sort) The new algorithm *invented, designed and implemented by the author, provide the speed of GCC Parallel Sort and a memory usage similar to TBB. With the additional advantage that don't need any library ( Open MP , TBB, Microsoft PPL …). Only need a C++11 compiler. An example shows you this : Sorting 100 000 000 random numbers of 64 bits. In a server with 32 threads. The results obtained was *Time spent* *Memory used (MB)* *GCC Parallel Sort* 1.05 secs 1560 MB *TBB Parallel Sort* 1.76 secs 783 MB *Block Indirect Sort* 0.97 secs 790 MB In the repository with the benchmark code you can find the benchmark results with several machines https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/… <https://github.com/fjtapia/sort_parallel_benchmark/tree/master/Linux64_GCC/…>In these files, you can see the rival is GCC. TBB is clearly surpassed, due to their internal algorithm. GCC divide the data, sorted independently by all the threads. And after for to merge do an easy process, and copy in an auxiliary memory, of the same size than the used by the data. All the threads are fed, but need the double of memory. The new algorithm, do the division, and sort independently, but for the merge, have a small buffer of 1024 elements, and when a part is moved to the buffer, must calculate which part must be copied in that place. Do the same but without the additional memory. Due this, need more CPU for to do the process. The hyper threading (HT) provide around a 30% more power to the processor, and usually in the machines with HT activate, the new algorithm is a bit faster than GCC, and with the HT deactivate is slower, and TBB is slower except when very big objects. But then the bottleneck is not the algorithm, is the data bus The new algorithm is a collection of bad algorithms when you have only 1 thread. But they are easily subdivided. This permit parallelize all the process and have fed all the threads. The new algorithm is documented in two articles - block_indirect_sort_brief_en.*:* (Introduction and graph benchmarks) - block_indirect_sort_en.pdf: (Introduction, detailed description of the algorithm and benchmarks.) If you want to test the benchmark in your machine it's easy. In the benchmark repository, you have the code used, and shell scripts for to compile and run, saving the results in a Results.txt file, for Linux GCC and CLANG and Windows Visual Studio 15 If you see any problem, mistake, something to improve or need any other information, please, say me. Yours Francisco * Invented: The algorithm had been ideate, designed and implemented beginning from zero from an old idea. After read hundreds of articles and books, I didn't find any similar. If you know something, please say me. But the important is not the author, is provide a fast, robust, and easy to use algorithm to the community of programmers.

1 0

[Boost 1.61] Open for bugfixes?
by Louis Dionne 29 Mar '16

29 Mar '16

Hi, On the release calendar [1], it is written that Boost 1.61 is currently open for bug fixes (since March 17). Some previous discussion left me under the impression that authors still had to ask a permission for pushing to their master branches. So, can I push (bugfixes) to Hana's master branch? Do I have to ask the permission when the calendar says it's open? Can I always rely exclusively on the official calendar at [1]? Thank you, Louis Dionne [1]: http://www.boost.org/community/index.html

2 2

[move][sort] Asymptotically optimal stable and in-place merging and sorting with no auxiliary memory
by Ion Gaztañaga 27 Mar '16

27 Mar '16

[Disclaimer, long e-mail, thank you for your attention] Hi to all, Some months ago I tried to gain interest from sorting experts about implementing stable and inplace merge [O(N)] or sort [O(NlongN)] algorithms that don't need additional memory. My main use case for these algorithms was lowering the complexity guarantees of range insertion functions offered by flat associative containers without any temporary allocation (the programmer does not expect allocations when capacity() is big enough to hold the new elements). On the other hand, I wanted those algorithms to be adaptive so as to take advantage of the extra capacity already allocated by flat containers. Of course, if a good implementation is available in Boost, it could be used as existing practice to change the worst-case complexities of some STL algorithms when no additional memory (e.g. get_temporary_buffer()) is available. After reviewing several algorithms from papers and some open source implementations, I decided to implement one of those algorithms. The implemented algorithm is based on the GrailSort algorithm developed by Andrey Astrelin. The main idea of the my adaptive_sort algorithm is explained by Andrey in an article published by the russian collaborative blog Habrahabr (http://habrahabr.ru/post/205290/) The algorithm is based on ideas explained by Huang and Langston in their paper "Fast Stable Merging and Sorting in Constant Extra Space (1989-1992" (http://comjnl.oxfordjournals.org/content/35/6/643.full.pdf) Since the implementation from (https://github.com/Mrrl/GrailSort) is macro-based, does not support non-memcopyable types and has a MIT license (which seems to be problematic for Boost), I implemented the algorithm from scratch following the article and taking ideas from Andrey's implementation. I added some new ideas and optimizations in order to reduce comparisons and elements moves. I must say that the implementation was really hard for someone like me without experience in sorting algorithms, the complexity is huge when compared with a classic mergesort algorithm. The implementation is already in develop and master branches but the develop branch contains more tests and a refactored and more documented code. So please check the code from the develop branch if interested. The implementation is still experimental and not production ready. What about benchmarks? I've only experimented in the oldest Visual compilers to make sure it correctly supports Boost.Move emulation and complexity guarantees were correct. Note that the STL algorithms tested in the benchmark might not be as fast as current implementations. In general, the new algorithms need much more elements moves than algorithms that allocate O(n) memory, but they are still quite fast when data movement is cheap (e.g. when a move constructor just copies a couple of pointers). These are the numbers for A VERY LIGHTWEIGHT object (a struct holding two integers, one for the key, another one to test the stability, don't take times very seriously, just pay attention to the number of comparisons/moves). ////////////////////////// ////////////////////////// STABLE MERGING ////////////////////////// ////////////////////////// - N: number of elements - NK: number of keys (0 means all keys different) - InplaceMerge: std::inplace_merge - Sqrt2AdaptMerge: adaptive_merge with an auxiliary buffer of 2*sqrt(N) elements - SqrtAdaptMerge: adaptive_merge with an auxiliary buffer of sqrt(N) elements - AdaptMerge: adaptive_merge with no external buffer - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by InplaceMerge ---------------------------------------------- Numbers produced by the bench_merge.cpp test in Boost.Move: ---------------------------------------------- - - N: 100001, NK: 511 - - InplaceMerge Cmp: 0.9989 Cpy: 1.5000 633.65us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2429 Cpy: 4.4209 910.16us ( 1.44) SqrtAdaptMerge Cmp: 4.2708 Cpy: 5.6712 1.63ms ( 2.57) AdaptMerge Cmp: 5.6014 Cpy: 8.7573 3.11ms ( 4.91) - - N: 100001, NK: 2047 - - InplaceMerge Cmp: 0.9998 Cpy: 1.5000 604.77us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2449 Cpy: 4.4483 934.83us ( 1.55) SqrtAdaptMerge Cmp: 2.0131 Cpy: 4.7609 1.12ms ( 1.85) AdaptMerge Cmp: 2.7608 Cpy: 11.1419 2.83ms ( 4.67) - - N: 100001, NK: 8191 - - InplaceMerge Cmp: 0.9999 Cpy: 1.5000 653.51us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2443 Cpy: 4.3179 943.86us ( 1.44) SqrtAdaptMerge Cmp: 1.4661 Cpy: 4.4348 998.62us ( 1.53) AdaptMerge Cmp: 1.7692 Cpy: 10.6292 2.54ms ( 3.89) - - N: 100001, NK: 32767 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 772.06us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2417 Cpy: 4.4317 1.03ms ( 1.33) SqrtAdaptMerge Cmp: 1.3320 Cpy: 4.4758 1.06ms ( 1.38) AdaptMerge Cmp: 1.5295 Cpy: 10.1233 2.44ms ( 3.16) - - N: 100001, NK: 0 - - InplaceMerge Cmp: 1.0000 Cpy: 1.5000 881.88us ( 1.00) Sqrt2AdaptMerge Cmp: 1.2387 Cpy: 4.4124 1.16ms ( 1.31) SqrtAdaptMerge Cmp: 1.2933 Cpy: 4.4412 1.20ms ( 1.36) AdaptMerge Cmp: 1.4110 Cpy: 7.5794 1.93ms ( 2.19) In general, with no memory and enough keys, the algorithm needs 7,5*N data moves and 1,5*N comparisons. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm might need upt to 5xN comparisons and 11xN moves. Number are improved if an auxiliary buffer of sqrt(N) elements is available. The number of comparisons and moves are even better than those shown in experimental results from several papers, but I still find them quite high. The algorithm needs some initial steps (e.g. unique key extraction) that are not amortized during the merge (adaptive_sort amortizes the initial steps much better ). I've derived the merge algorithm from the sorting algorithm so maybe there is room for improvement (I've invested much more time in the sorting algorithm). ////////////////////////// ////////////////////////// STABLE SORTING ////////////////////////// ////////////////////////// Numbers when sorting: - N: number of elements - NK: number of keys (0 means all keys different) - MergeSort: A half-copying mergesort (it only needs N/2 auxiliary memory) implemented in boost/move/algo/detail/merge_sort.hpp. Based on the paper "Fast mergesort implementation based on half-copying merge algorithm" by Cezary Juszczak (http://kicia.ift.uni.wroc.pl/algorytmy/mergesortpaper.pdf) Usually faster than std implementations with less auxiliary memory. - StableSort: std::stable_sort - HeapSort: std::heap_sort - QuartAdaptSort: adaptive_sort with N/4 auxiliary memory - Sqrt2AdaptSort: adaptive_sort with 2*sqrt(N) auxiliary memory - SqrtAdaptSort: adaptive_sort with sqrt(N) auxiliary memory - SqrtHAdaptSor: adaptive_sort with sqrt(N)/2 auxiliary memory - AdaptSort: adaptive_sort with no auxiliary memory - Cmp: number of comparisons / N - Cpy: number of move constructor/assignments / N - (ratio): time of execution / time needed by MergeSort [numbers produced by the bench_sort.cpp test in Boost.Move] - - N: 100001, NK: 511 - - MergeSort Cmp: 16.379 Cpy: 16.707 6.49ms ( 1.00) StableSort Cmp: 20.594 Cpy: 22.978 10.85ms ( 1.67) HeapSort Cmp: 16.992 Cpy: 22.098 10.98ms ( 1.69) QuartAdaptSort Cmp: 17.659 Cpy: 26.314 8.34ms ( 1.29) Sqrt2AdaptSort Cmp: 17.829 Cpy: 35.340 9.90ms ( 1.53) SqrtAdaptSort Cmp: 27.805 Cpy: 56.059 19.48ms ( 3.00) SqrtHAdaptSort Cmp: 27.356 Cpy: 60.375 20.35ms ( 3.14) AdaptSort Cmp: 27.352 Cpy: 67.889 21.83ms ( 3.36) - - N: 100001, NK: 8191 - - MergeSort Cmp: 16.394 Cpy: 16.725 7.47ms ( 1.00) StableSort Cmp: 20.578 Cpy: 22.978 11.92ms ( 1.60) HeapSort Cmp: 16.992 Cpy: 22.099 11.91ms ( 1.59) QuartAdaptSort Cmp: 17.676 Cpy: 26.362 9.26ms ( 1.24) Sqrt2AdaptSort Cmp: 17.847 Cpy: 35.747 10.93ms ( 1.46) SqrtAdaptSort Cmp: 18.977 Cpy: 41.641 12.19ms ( 1.63) SqrtHAdaptSort Cmp: 17.076 Cpy: 57.799 15.47ms ( 2.07) AdaptSort Cmp: 17.090 Cpy: 67.179 17.37ms ( 2.33) - - N: 100001, NK: 32767 - - MergeSort Cmp: 16.395 Cpy: 16.727 7.66ms ( 1.00) StableSort Cmp: 20.581 Cpy: 22.986 12.16ms ( 1.59) HeapSort Cmp: 16.994 Cpy: 22.099 11.96ms ( 1.56) QuartAdaptSort Cmp: 17.674 Cpy: 26.319 9.47ms ( 1.24) Sqrt2AdaptSort Cmp: 17.833 Cpy: 35.792 11.16ms ( 1.46) SqrtAdaptSort Cmp: 18.967 Cpy: 41.604 12.42ms ( 1.62) SqrtHAdaptSort Cmp: 17.065 Cpy: 57.756 15.71ms ( 2.05) AdaptSort Cmp: 17.081 Cpy: 67.131 18.32ms ( 2.39) - - N: 100001, NK: 0 - - MergeSort Cmp: 16.399 Cpy: 16.731 7.76ms ( 1.00) StableSort Cmp: 20.521 Cpy: 22.920 12.23ms ( 1.58) HeapSort Cmp: 16.991 Cpy: 22.094 11.85ms ( 1.53) QuartAdaptSort Cmp: 17.671 Cpy: 26.380 9.50ms ( 1.22) Sqrt2AdaptSort Cmp: 17.825 Cpy: 35.653 11.17ms ( 1.44) SqrtAdaptSort Cmp: 18.954 Cpy: 41.545 12.42ms ( 1.60) SqrtHAdaptSort Cmp: 17.058 Cpy: 57.694 15.66ms ( 2.02) AdaptSort Cmp: 17.072 Cpy: 67.072 17.57ms ( 2.26) In general, with no memory and enough keys, the algorithm needs nearly optimal comparisons and significantly more (4x) data movements. Data locality is quite high and with cheap-moving types the overall time can be just two-three times slower. With fewer keys, the algorithm performs worse but it's quite competitive. When extra memory (e.g. sqrt(N)) is available, the algorithm is quite fast with cheap-moving types. //////////////////////////////////////////// Final words: The effort to implement the algorithms was big and I couldn't fix many open bugs in my libraries, so in the following months I don't expect to invest much time on this. At least I wanted to publicly share the committed implementation so that it can be improved by sorting experts. I don't claim these algorithms are groundbreaking or even useful for many programmers, but they might be a good starting point. I'm not happy with the implementation as the algorithm is complicated and I' haven't found a way to simplify it further without noticeable slowdowns. For those interested in the implementation and the algorithm: please contribute correct benchmarks and testing, as there are very few open source implementations of similar algorithms. Any optimization, patch or bug report is welcome. Best, Ion

4 9

Boost 1.61.0 Beta 1 Release Candidate 2
by Vladimir Prus 26 Mar '16

26 Mar '16

Second set of release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The changes from RC1 are: * Top-level directory in the archive matches the name * Zip and 7z archives use CRLF line endings The known issues are: * Documentation build has some wrong-location, extra-files and broken-links issues. * There was a report of Boost.Context issue on OSX Release managers believe these issues are not blocking beta 1. The SHA1 checksums are as follows: 4d3c83d3a802d3dd12d4f2d516b3fcf076f6f6ba boost_1_61_0_b1_rc2.7z 8c6ac7326a3cabcabf6c7876052b73e0d41fc36d boost_1_61_0_b1_rc2.tar.bz2 e82b8ff7c3ad5b08c7dbeac1ea85fcf707a1cd4d boost_1_61_0_b1_rc2.tar.gz 7292e8fdac0566fe098a60a197a5722d381842d3 boost_1_61_0_b1_rc2.zip The SHA256 checksums are as follows: bc8341bfb8c6621319ad9eb732179fc7ec4da35c3cefc31b613f83ec3df10361 boost_1_61_0_b1_rc2.7z c0f06c78c195af9079773a2b250674244f1899ec81e84d5455f0761f1d888a16 boost_1_61_0_b1_rc2.tar.bz2 400fa0949aa201d993bf116461365e5d44904a3f8db6412f4f40f2b4ab490405 boost_1_61_0_b1_rc2.tar.gz d75688ecad601303dda2658e9a3d06f406dd4dc8e2c13c36bdadcac0a11dcffa boost_1_61_0_b1_rc2.zip Thanks! -- The release managers

9 15