September 2015 - 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

[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

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

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

Request for review: Boost.Fit
by paul Fultz 06 Oct '15

06 Oct '15

Hi All, Boost.Fit is a header-only function utility library for C++11. It supports both gcc, clang and visual studio. More info can be found here: https://github.com/pfultz2/Fit I would like to take this time to ask for a review. Vicente Botet has mentioned he could be a review manager. So I would like to move forward in scheduling a formal review. I plan to boostify the library for the formal review. In addition, I would like to ask for an informal review at this time. If anyone has some feedback or questions, that would be greatly appreciated. Thanks, Paul

6 10

Boost.GSL?
by David Sankel 05 Oct '15

05 Oct '15

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines. I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change. What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library? -- David Sankel [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL

9 16

Boost perf tests?
by Stephan T. Lavavej 03 Oct '15

03 Oct '15

Hi Boost devs, Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved. I looked around briefly, but didn't find anything. Thanks, STL

6 6

[optional] Specializing optional to save space
by David Stone 03 Oct '15

03 Oct '15

Andrzej posted another thread about creating a new compact_optional class. The goal of this class is to make it easy to create a new optional type with a special sentinel value. This allows easy customization per instance of an optional value. This post is about the opposite approach: making it easier to specialize optional to provide special behavior for all instances of a given optional type. When I bring this up, people often compare it to the vector<bool> specialization, but this is a completely different issue. The problem of vector<bool> is that it does not actually store a bool anywhere, so it cannot return a reference to one. This would still store a T somewhere. For the rest of the discussion, I will be assuming a typical standard library implementation on a 64-bit system. Whenever I talk about specific sizes of objects, mentally insert "on most common systems". The principles apply generally. Consider the case of optional<std::string>. Using the naive implementation, this object is 8 bytes larger than std::string, due to alignment requirements. However, there are certain representations of std::string that are not actually possible. For instance, for common implementations of std::string you cannot have std::string::size() == std::numeric_limits<std::string::size_type>::max() *. We can take advantage of this if our std::string implementation stores the capacity as an integer value, rather than a pointer to the end of the storage. Therefore, we could have implementations that look something like this: class string { friend optional<string>; }; template<> class optional<std::string> { optional(none_t) { // Use friendship to just set capacity to sentinel value } explicit operator bool() const { return m_data.capacity() == std::numeric_limits<std::string::size_type>::max(); } }; optional<std::string> still stores std::string in it, so operator*() works just fine. The initialized check is still just comparing a field against a compile-time constant. This makes this purely a space optimization that cannot be detected by the user, unless they use sizeof(optional<std::string>). I believe all of this is possible today with the current specification of boost::optional (and would definitely be allowed for the proposed std::experimental::optional). However, this requires the creator of each specialization to implement the full optional interface. What's more, it is especially tricky to specialize optional for a class template when you only want to specialize on certain specializations of the class template. My use case for this is my bounded::integer library. This library lets you specify the bounds of your integer as template parameters. If your bounded::integer has a narrower range than its underlying integer, you can take advantage of this to make a more space-efficient optional. If, however, the bounded::integer min and max are equal to that of the underlying type, there is no extra space and we want the default optional implementation. With the current specialization approach, it is the responsibility of the specializer to reimplement all of optional. A better approach to easily support this space optimization is as follows: optional contains an instance of optional_storage<value_type>. optional_storage has a much narrower interface: * optional_storage() leaves it uninitialized * optional_storage(in_place_t, T && ...) constructs the value directly with the variadic arguments * emplace(T && ...) constructs an object when there may be one in existence already * reset() destroys the contained object and sets the storage to uninitialized * is_initialized() says whether the contained object is initialized. This could be replaced with explicit operator bool(); I have no preference. * value() returns a reference to the value We need both the constructor and the emplace function to allow literal optional types. This is because for the general case, emplace calls placement new, which is not allowed in a constexpr function. This solves the problem of specializers having to implement the entire interface of optional just to change how the uninitialized state is stored. However, it still does not solve the problem I mentioned earlier about allowing easy use of the default storage policy for some specializations of your own class template. To solve that, we need one more class: default_optional_storage. default_optional_storage<T> is a literal type if T is a literal type (in practice, std::is_trivially_destructible<T>::value is all you really need to test). It implements the same interface as optional_storage<T>. The default implementation of optional_storage<T> is template<typename T> struct optional_storage : default_optional_storage<T> { private: using base = default_optional_storage<T>; public: using base::base; }; This means that the optional library would have at least three classes in its public interface: * optional * optional_storage * default_optional_storage To see a working example of this (including a specialization for bounded::integer), see https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… * The reason is that std::string::size_type is a typedef for std::size_t, which is equivalent in range to std::uint64_t. However, std::iterator_traits<std::string::iterator>::difference_type is std::ptrdiff_t, which is equivalent in range to std::int64_t. This means that for the largest std::string, std::distance(begin(), end()) cannot be more than std::numeric_limits<std::ptrdiff_t>::max(), which is less than std::numeric_limits<std::size_t>::max().

6 15

Compiler warnings after boost update
by Auer, Jens 03 Oct '15

03 Oct '15

Hi, we compile with high compiler warnings setting (-Wall, -Wpedantic), and treat compiler warnings as errors. Recently, I had to upgrade the boost library version from 1.53 to at least 1.55. Since there was no package available, I compiled it by hand from the source code. With 1.53, everything compiled fine, but with the newer version my builds now break because the boost library generates a lot of warnings, e.g. /cots/boost-1.55/include/boost/iterator/iterator_concepts.hpp: At global scope: /cots/boost-1.55/include/boost/mpl/assert.hpp:288:54: error: use of old-style cast [-Werror=old-style-cast] boost::mpl::assert_arg( (void (*) pred)0, 1 ) \ ^ /cots/boost-1.55/include/boost/mpl/assert.hpp:59:58: note: in definition of macro ‘BOOST_MPL_AUX_ASSERT_CONSTANT’ # define BOOST_MPL_AUX_ASSERT_CONSTANT(T, expr) enum { expr } /cots/boost-1.55/include/boost/range/algorithm/equal.hpp: In function ‘bool boost::range::equal(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’: /cots/boost-1.55/include/boost/concept/detail/general.hpp:71:20: error: typedef ‘boost_concept_check185’ locally defined but not used [-Werror=unused-local-typedefs] BOOST_PP_CAT(boost_concept_check,__LINE__) /cots/boost-1.55/include/boost/property_tree/xml_parser.hpp:52:59: required from ‘void boost::property_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type::value_type = char]’ /home/auerj/MDAF/src/commons/src/crypto/KeyFileReader.cpp:43:34: required from here /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] if (first_attribute()) ^ /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1211:45: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] These are just some examples, there are literally hundreds of warnings. It is enough to just include ptree.hpp, but other headers have the same issue. I am wondering why this came up after the update. Is it a configuration problem during the build of the boost libraries, or is it an issue in the boost libraries? I find it hard to believe that the code quality changed so much between the versions. What is the policy of the boost project concerning compiler warnings in installation headers? I would assume that the libraries should compile without warnings on supported compilers, either because there are no issues, or because warnings are disabled in the boost headers. Best wishes, Jens -- Jens Auer | CGI | Software-Engineer CGI (Germany) GmbH & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

10 14

[build][regression] Problems when trying to run automated regression tests for MSVC-7.1
by Ion Gaztañaga 03 Oct '15

03 Oct '15

Hi, Since Boost 1.55 minimum requirements include Visual C++ 2003. Since currently there is no regression report for this compiler, I'm trying to follow the steps detailed here and try to fill the gap: http://www.boost.org/development/running_regression_tests.html All the source code is downloaded, my user-config.jam only contains "using msvc ;" but it seems that Boost.Build continues to be broken for MSVC-7.1: <output> notice: Loading user-config configuration file 'user-config.jam' from 'C:/Users/igaztanaga'. notice: [msvc-cfg] msvc-7.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' for msvc, condition <toolset>msvc-7.1 C:/boost/develop/boost_bb/src/tools\msvc.jam:1072: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup ) * called with: ( 7.1 : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7 : <command>C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe : i386 : : x86 : vcvars32.bat ) * missing argument global-setup C:/boost/develop/boost_bb/src/tools\msvc.jam:798:see definition of rule 'generate-setup-cmd' being called C:/boost/develop/boost_bb/src/tools\msvc.jam:201: in configure C:/boost/develop/boost_bb/src/tools\msvc.jam:153: in msvc.init C:/boost/develop/boost_bb/src/build\toolset.jam:43: in using C:\Users\igaztanaga\user-config.jam:49: in modules.load c:/boost/develop/boost_bb/src\build-system.jam:249: in load-config c:/boost/develop/boost_bb/src\build-system.jam:389: in load-configuration-files c:/boost/develop/boost_bb/src\build-system.jam:524: in load C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build C:\boost\develop\boost_regression\boost-build.jam:57: in module scope </output> I can't figure out what's wrong in msvc.jam. Comments on that file suggest that MSVC-7.1 should be supported although it seems that since MSVC-8.0 the configuration script architecture changed. I'd be glad if any Boost.Build expert could have a look at this issue. Many thanks, Ion PS: Full output for command... python run.py --runner=igaztanaga --toolsets=msvc-7.1 --tag=develop --incremental --libraries=move --have-source > output.txt ...attached.

2 4

compact_optional -- prompting interest
by Andrzej Krzemienski 02 Oct '15

02 Oct '15

Hi Everyone, I would like to inquire if there would be an interest in Boost in another library for storing optional objects, but working under different design goals. Compact optional T has (or can have) the same sizeof as T. It uses one indicated value of T to represent the "empty" (or "singular") value. You can declare it like this: compact_optional<evp_int<int, -1>> oi; This reads: we have an optional int, with type int inside, where -1 represents the empty value. It can never have a genuine (non-empty value -1). This can be used, for instance, to wrap the std::string::npos into: compact_optional<evp_int<string::size_type, string::npos>> With the same memory layout as std::string::size_type, but with the special syntax for managing the singular value. It is not meant to be an alternative to Boost.Optional: it targets a different application space. The (single-header) implementation is at: https://github.com/akrzemi1/compact_optional The documentation is at: https://github.com/akrzemi1/compact_optional/blob/master/documentation.md For the motivation and design rationale see this article: https://akrzemi1.wordpress.com/2015/07/15/efficient-optional-values/ Any feedback is welcome. Regards, &rzej

17 43

Re: [boost] [regression] Tests for 'develop' not showing
by Tom Kent 30 Sep '15

30 Sep '15

On Wed, Sep 23, 2015 at 8:16 AM, Tom Kent <lists(a)teeks99.com> wrote: > > On Tue, Sep 22, 2015 at 9:53 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: >> >> > On Wed, Sep 9, 2015 at 4:35 PM Edward Diener <eldiener(a)tropicsoft.com> >>>> > wrote: >>>> > >>>> > > Trying >>>> > > >>>> http://www.boost.org/development/tests/develop/developer/summary.html I >>>> > > get: >>>> > > >>>> > > "Error extracting file: The specified zipfile was not found." >>>> > > >>>> >>>> And they are messed up again. Tom can you look into your side of this? >> When I generated the results I got the ZIP files to be 1.5GiB and 2.0GiB, >> approximately, for develop and master, respectively. Yet what I see on the >> web site now is 1.5GiB and 200MiB. Which is clearly incorrect. And it's >> precisely the shorter ZIP, i.e. master.zip, that now doesn't work. I.e >> browsing develop results works, but not browsing master results. >> > > Over the last week I've seen both the master and develop results showing > the zip error message. > > I just noticed that in the last master run, I had a segfault in the > processing: > > tomkent@eddie:~/tmp/boost_reports/boost-reports⟫ tail master.log > Reading failures markup > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/BP > x86_64 C++11.xml > Merging expected results > Generating links pages > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/CrystaX.NET-apilevel-19-armeabi-v7a-hard.xml > Merging expected results > Generating links pages > Reading > /home/tomkent/tmp/boost_reports/boost-reports/master/incoming/master/processed/CrystaX.NET-apilevel-19-armeabi-v7a.xml > Merging expected results > Segmentation fault (core dumped) > > I'll look into it more tonight. > Tom > It looks like running the reports (esp master) is taking much longer...up to 2hrs. I had a cron job running every hour, which corrupted things when it was kicked off a second time while the first was still running. I've made a change in the script to setup a lock file, so that only one instance will run and submitted a pull request against the regression repo. It's already running on my report generator, so hopefully the problem won't show up again. If anyone sees it please let me know. Tom

4 6

[git] Testing and Pushing updates to library
by Artyom Beilis 30 Sep '15

30 Sep '15

Hello, I'm back to Boost after my last commits were in svn and now I need to make sure I do stuff correctly in git/github. In boost-svn there were trunk for development and release for up-to date release, currently master is what "release branch" is svn was and develop is what trunk? Q: Is it correct. I have several fixes - I pushed them to master branch of Boost.Locale library. https://github.com/boostorg/locale/compare/26482aa844...ea55386441 I did same for develop (I hope correctly) Q: Is pushing changes to master it enough to get them into next boost release? I had some strange behavior of "detached Head" so I needed to create small temporary local branch and than merge it to master... Q: is it normal? Can't I commit/push directly to master without temporary branch? Testing - in svn there were regression tests for both release and trunk branches of svn... Q: What happens now with regression tests I cound't find the information in the wiki. Thanks. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

2 1

how to pass -std=c++14 to b2 while building boost libraries
by Frédéric Bron 30 Sep '15

30 Sep '15

Hi, I would like to build a c++14 version of boost libraries on my system. I have the intel compiler (15.0.3) on a x86_64 linux machine (2.6.32-279.19.1.el6.x86_64). I do the following: 1. build b2 CC="icc" CFLAGS="-O2 -DNDEBUG -xhost" CXX="icpc" CXXFLAGS="-O2 -DNDEBUG -xhost -std=c++14" AR="ar" AS="as" RANLIB="ranlib" ./bootstrap.sh --without-icu --prefix=/myusr/icc-15.0.3-c++14-release/boost --with-toolset=intel-linux 2. edit user-config.jam My user-config.jam, located in the boost source directory contains: using intel-linux : : icpc : <compilerflags>-xhost <compilerflags>-std=c++14 ; 3. run b2 ./b2 -d2 -j16 -sBZIP2_INCLUDE=/myusr/icc-15.0.3-c++14-release/bzip2/include -sBZIP2_LIBPATH=/myusr/icc-15.0.3-c++14-release/bzip2/lib -sZLIB_INCLUDE=/myusr/icc-15.0.3-c++14-release/zlib/include -sZLIB_LIBPATH=/myusr/icc-15.0.3-c++14-release/zlib/lib --layout=system --user-config=user-config.jam --without-mpi --without-python --without-context --without-coroutine link=static threading=multi runtime-link=shared target-os=linux address-model=64 variant=release install The problem I see is that the flag -std=c++14 is not passed to the compiler. For example, this is an output of b2: "icpc" -c -xc++ -w1 -inline-level=2 -O3 -ip -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/filesystem/build/intel-linux/release/link-static/threading-multi/codecvt_error_category.o" "libs/filesystem/src/codecvt_error_category.cpp" no trace of -std=c++14 flag. How can I send that flag to the compiler? Apparently, the problem is the same when using g++ 5.2.0. Frédéric

2 2

[boost.build] broken link
by Frédéric Bron 30 Sep '15

30 Sep '15

On this page: http://www.boost.org/doc/libs/1_59_0/tools/build/index.html the link to the documentation is broken: http://www.boost.org/doc/libs/1_59_0/tools/build/doc/html/index.html error message: 404 Not Found File "/home/www/live.boost.org/common/code/../../doc/archives/boost_1_59_0/tools/build/doc/html/index.html" not found. Unable to find file. Cheers, Frédéric

2 1

develop tests
by Robert Ramey 29 Sep '15

29 Sep '15

When I try to look at the tests of the develop branch at http://www.boost.org/development/tests/develop/developer/serialization.html I get an error message. Has this been resolved yet? Is there anything I have to do? Robert Ramey

1 0

Variadics bug in MSVC-12.0
by Gennadiy Rozental 29 Sep '15

29 Sep '15

Hi, While working on improving of implementation of data driven tests, I found rather annoying bug in MSVC-12.0 with variadic templates. The code seems to work fine with msvc-14.0, gcc 4.8 and clang 3.4. I did not try msvc- 13.0. Does anyone know a workaround? Example follows (try to comment on/off line: auto const& t3). Gennadiy // C++ 14 index_sequence template <std::size_t... Ns> struct index_sequence {}; template<typename IS1, typename IS2> struct merge_index_sequence; template <std::size_t... Ns1, std::size_t... Ns2> struct merge_index_sequence<index_sequence<Ns1...>, index_sequence<Ns2...>> { typedef index_sequence<Ns1..., Ns2...> type; }; template <std::size_t B, std::size_t E, typename Enabler = void> struct make_index_sequence { typedef typename merge_index_sequence< typename make_index_sequence<B, (B + E)/2>::type, typename make_index_sequence<(B + E)/2, E>::type>::type type; }; template <std::size_t B, std::size_t E> struct make_index_sequence<B, E, typename std::enable_if<E == B + 1, void>::type> { typedef index_sequence<B> type; }; template <typename... T> using index_sequence_for = typename make_index_sequence<0, sizeof...(T)>::type; ////////////////////////////////////////////////////////////////////////// template<typename T1, typename T2> struct merged_tuple { typedef std::tuple<T1,T2> type; typedef std::tuple<T1 const&,T2 const&> ref; }; template<typename T1, typename ...T> struct merged_tuple<T1, std::tuple<T...>> { typedef std::tuple<T1, T...> type; typedef std::tuple<T1 const&, T const&...> ref; }; template<typename ...T, typename T1> struct merged_tuple<std::tuple<T...>, T1> { typedef std::tuple<T..., T1> type; typedef std::tuple<T const&..., T1 const&> ref; }; template<typename ...T1, typename ...T2> struct merged_tuple<std::tuple<T1...>, std::tuple<T2...>> { typedef std::tuple<T1..., T2...> type; typedef std::tuple<T1 const&..., T2 const&...> ref; }; template<typename ...T1, typename ...T2, std::size_t ...I1, std::size_t ...I2> inline typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref tuple_merge_impl( std::tuple<T1 const&...> const& a1, std::tuple<T2 const&...> const& a2, index_sequence<I1...> const& , index_sequence<I2...> const& ) { using ref_type = typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref; return ref_type( std::get<I1>(a1)..., std::get<I2>(a2)... ); } template<typename ...T1, typename ...T2> inline typename merged_tuple<std::tuple<T1...>, std::tuple<T2...>>::ref tuple_merge_impl( std::tuple<T1 const&...> const& a1, std::tuple<T2 const&...> const& a2 ) { return tuple_merge_impl( a1, a2, index_sequence_for<T1...>{}, index_sequence_for<T2...>{} ); } template<typename T> inline std::tuple<T const&> as_tuple( T const& arg ) { return std::tuple<T const&>( arg ); } template<typename ...T> inline std::tuple<T...> const& as_tuple( std::tuple<T...> const& arg ) { return arg; } template<typename T1, typename T2> inline typename merged_tuple<T1, T2>::ref tuple_merge( T1 const& a1, T2 const& a2 ) { return tuple_merge_impl( as_tuple( a1 ), as_tuple( a2 ) ); } int main() { auto const& t1 = tuple_merge( 1, 2 ); auto const& t2 = tuple_merge( 3, 4 ); auto const& t3 = tuple_merge( t1, 5 ); auto const& t4 = tuple_merge( 6, t2 ); return 0; }

1 0

Boost.Test: runtime parameter framework update
by Gennadiy Rozental 29 Sep '15

29 Sep '15

Hi, Over the years there were complains about the interface and functionality of the Boost.Test Unit Test Framework(UTF)'s runtime parameters. Primarily command line arguments handling, but also documentation and few other concerns. This update addresses all these issues, introduces few new features and makes runtime parameters much more user friendly. In addition new implementation significantly simpler. Here is short summary of fixed issues and significant new features: * (new) UTF now requires all user defined arguments to follow UTF specific arguments. They are separated by "--" marker. For example: test.exe --random -- /myarg:17 * (bug) UTF now properly supports arguments with spaces. For example: test.exe --log_sink="file name.txt" * (bug) UTF now reports missing value in arguments. For example: test.exe --log_sink=, produces: Missing an argument value for the parameter log_level in the argument -- log_level= * (bug/new) UTF now reports invalid parameters. Moreover, UTF now supports hints with possible typos. For example: test.exe --colour, produces: An unrecognized parameter in the argument --colour Did you mean one of these? color_output Suggestion is shown when close (1 char distance from unambiguous parameter name) exists. * (new) UTF now report possible ambiguous parameters. For example: test.exe --log=all, produces: An ambiguous parameter name in the argument --log=all Did you mean one of these? log_format log_level log_sink * (new) UTF parameter help now accepts optional parameter name. Moreover you can actually "guess" the name by providing just unambiguous prefix. In this case it shows detailed information about requested parameter, including semantic, possible values and formats. For example: test.exe --help=list_con, produces: Parameter: list_content Lists the content of test tree - names of all test suites and test cases. Command line formats: --list_content[=<HRF|DOT>] Environment variable: BOOST_TEST_LIST_CONTENT Parameter list_content instructs the framework to list the content of the test module instead of executing the test cases. Parameter accepts optional string value indicating the format of the output. Currently the framework supports two formats: human readable format (HRF) and dot graph format (DOT). If value is omitted HRF value is assumed. The changes will be released with next release of boost. Any comments are welcome. Gennadiy

1 0

Graphical debugging extension for VS2015 (Container, Geometry, Polygon, Variant, ...)
by Adam Wulkiewicz 29 Sep '15

29 Sep '15

Hi, For some time now I've been thinking about extending the capabilities of a debugger and to visualize data in more convenient way than the raw numbers. It's obvious to me that in many cases variables could be graphically visualized, in many cases this is the "natural" representation, this would greately simplify the debugging. I haven't found anything like it so I've decided to play with the VS2015 extensions, mostly because they're easy to write. This is what I came up with (see the readme): https://github.com/awulkiew/graphical-debugging Besides adding commonly used native visualizers for types from some Boost libraries it allows to display their graphical representation. The extension support Boost.Geometry models and other types used internally in this library, Boost.Polygon models (polygon_set_data is missing) and boost::variant storing geometries. As a bonus, it's possible to watch containers of values (some STL containers as well as boost::array and contiguous containers from Boost.Container) as charts. Maybe if there were enough interest it'd be worth to extend it and/or to add to the official VS extensions gallery. I'm a Boost.Geometry developer so in the future I plan to support all of the coordinate systems supported by the library, maybe other internals and basically anything that helps me with the development. But I can imagine that variables of types from various Boost libraries could also be visualized, e.g. Polygon's voronoi diagram and internals, Math's quaternions as 3D Axis-Angle, std::complex as a point on a plane, containers of complex numbers and in general arbitrary types represented somehow as a 1D, 2D or 3D objects, CircularBuffer e.g. as a pie chart, BGL's graphs, maybe GIL's images, Interprocess' shared memory blocks?, etc. So feel free to share suggestions and contribute if you like. Regards, Adam

3 5

Trying out CLion.. Free license..
by Rene Rivera 29 Sep '15

29 Sep '15

As some of you are aware JetBrains recently release a new IDE that has some rather cool features (re: <https://www.jetbrains.com/clion/>) for C++ programmers. I am personally interested in using CLion for Boost work. In particular I'm hoping to write a CLion plug-in that integrates Boost Build into the IDE. And hence I've have taken it upon myself to arrange for Boost developers to get licenses for library authors to use, if they so wish. If you are interested in getting a CLion license and are a current Boost Library author here's what I need: * An email from you requesting that you want a license. * In that email indicate which Boost libraries you are an author, or maintainer, of. * Send the email from an account that you want me to send you the license when we get it. I want to avoid having to update email information a year from now when I need to renew the licenses. * You have until the end of this week, roughly, to send that email. I'll collect that and request the Boost licenses from JetBrains. And "pass" them out with instructions as needed. Rene. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 7

CLion plug-in for Boost.Build (was: Trying out CLion.. Free license..)
by Mateusz Loskot 28 Sep '15

28 Sep '15

On 28 September 2015 at 21:19, Rene Rivera <grafikrobot(a)gmail.com> wrote: > On Mon, Sep 28, 2015 at 2:14 PM, Robert Ramey <ramey(a)rrsd.com> wrote: >> On 9/28/15 11:45 AM, Rene Rivera wrote: >> >>> As some of you are aware JetBrains recently release a new IDE that has >>> some >>> rather cool features (re: <https://www.jetbrains.com/clion/>) for C++ >>> programmers. I am personally interested in using CLion for Boost work. In >>> particular I'm hoping to write a CLion plug-in that integrates Boost Build >>> into the IDE. And hence I've have taken it upon myself to arrange for >>> Boost >>> developers to get licenses for library authors to use, if they so wish. >>> >> >> Hmm - wouldn't it be easier just to use CMake. You wouldn't have to write >> any plugin. The serialization library includes CMake files for that >> library's build and test and it works quite well. >> > > IMO no.. But I know that opinions differ ;-) Some time ago, I developed basic Boost.Build plugin for Qt Creator https://github.com/mloskot/qt-creator-plugin-boostbuild/ which interacts with the b2.exe command line. At that time, I also briefely discussed some API ideas with Volodya. Later, Volodya implemented the Boost.Build API and server mode http://lists.boost.org/boost-build/2015/03/27906.php May I ask, which option are you going to choose for your plugin? Is it going to be the command line approach, the new BB API or anything else? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[test] Regression - overloaded virtual function "boost::unit_test::test_observer::test_unit_skipped" is only partially overridden
by Vicente J. Botet Escriba 25 Sep '15

25 Sep '15

Hi, there is a regression in Boost.Test. Test output: boost/bin.v2/libs/test/build/intel-linux/release/link-static/threading-multi Rev 32fc9643eb674d60616412bb427bb6e0f0300cc0 / Thu, 24 Sep 2015 19:13:08 +0000 Compile [2015-09-24 20:55:11 UTC]: succeed "icpc" -c -xc++ -w2 -inline-level=2 -O3 -ip -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TIMER_STATIC_LINK=1 -DNDEBUG -I".." -c -o "/boosttest/develop/results/boost/bin.v2/libs/test/build/intel-linux/release/link-static/threading-multi/test_tools.o" "../libs/test/src/test_tools.cpp" In file included from ../boost/test/impl/test_tools.ipp(19), from ../libs/test/src/test_tools.cpp(16): ../boost/test/unit_test_log.hpp(88): warning #654: overloaded virtual function "boost::unit_test::test_observer::test_unit_skipped" is only partially overridden in class "boost::unit_test::unit_test_log_t" class BOOST_TEST_DECL unit_test_log_t : public test_observer, public singleton<unit_test_log_t> { ^ remark #11074: Inlining inhibited by limit max-size remark #11074: Inlining inhibited by limit max-total-size remark #11076: To get full report use -qopt-report=4 -qopt-report-phase ipo Vicente

1 0

boost_1_59_0 build failures
by Karen Shaeffer 24 Sep '15

24 Sep '15

Hello, I downloaded boost_1_59_0 and built the whole set of libraries. gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 ./b2 install warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) - lockfree boost::atomic_flag : yes (cached) - has_icu builds : yes (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - iconv (libc) : yes (cached) - icu : yes (cached) - compiler-supports-visibility : yes (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : yes (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : yes (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - coroutine2 : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...patience... ...found 34509 targets... ...updating 8 targets... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a(clean) for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.a for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/link-static/threading-multi>libboost_iostreams.a... gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o libs/iostreams/src/bzip2.cpp:20:56: fatal error: bzlib.h: No such file or directory #include "bzlib.h" // Julian Seward's "bzip.h" header. ^ compilation terminated. "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_IOSTREAMS_DYN_LINK=1 -DBOOST_IOSTREAMS_USE_DEPRECATED -DNDEBUG -I"." -c -o "bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o" "libs/iostreams/src/bzip2.cpp" ...failed gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi/bzip2.o... ...skipped <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>bzip2.o... ...skipped <p/usr/local/lib>libboost_iostreams.so.1.59.0 for lack of <pbin.v2/libs/iostreams/build/gcc-4.8/release/threading-multi>libboost_iostreams.so.1.59.0... ...skipped <p/usr/local/lib>libboost_iostreams.so for lack of <p/usr/local/lib>libboost_iostreams.so.1.59.0... ...failed updating 2 targets... ...skipped 6 targets... Is that expected? thanks, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path. Zen proverb

2 1

Fwd: [sort][container] Challenge for sorting experts, an improved stable sort
by Francisco José Tapia 23 Sep '15

23 Sep '15

Hi Jon, If the elements in the flat associative container are sorted, you need only to sort the elements to insert and after do a fusion of the two parts. If your container admit repeated elements, you can use the std::sort, if not, you must use an stable sort , and delete the repeated. You have several algorithms for to do a stable sort. In the library we are developing (https://github.com/fjtapia/sort_parallel ) you have a smart_merge_sort, which is a very fast stable sort and use only one half of the memory used by the data, is exception safe and use the move semantics I didn't see any implementation of the stable sort algorithms without additional memory, in any library GCC, TBB, IPP … I suppose because they are slow. If you have 100 elements and want to insert 30 elements, need to resize the vector to 130 elements, the last 30 are empty. If you have other vector with the data to insert, you can use smart_merge_sort, and use as auxiliary memory the last 15 elements of the main vector. After sort, delete the repeated elements. And with the two vectors you must do a half_merge fusion , and all is done. With this method you need only the vector for to sort the elements to insert. If you want I can write a small program doing this, using the code of the library.

2 2

[sort][container] Challenge for sorting experts, an improved stable sort
by Ion Gaztañaga 23 Sep '15

23 Sep '15

Hi, I'm trying to improve insertion times for flat associative containers. In range insertions one optimization is to insert the whole range in the end of the container and sort the whole vector instead of trying a loop. An additional optimization proposed in the mailing list is to have an option to create externally the internal vector type of the flat map/set, fill it and then try to move it into the flat container. That requires sorting the moved vector (and removing duplicates if needed). I could try to use std::sort/std::stable_sort but there are some problems: -> Non-portable for C++03 compilers and Boost.Move, and Boost.Container fully supports those platforms. -> Additional O(N) temporary memory for stable sorting. Usually this means a temporary N element array, although there are algorithm to use only N/2 temporary elements. With big containers, this is a lot of memory. So I started analyzing several papers and implementations to see if a custom implementation was possible, but I felt Boost.Sort could be a good place to have that implementation and the Boost community a good place to discuss design alternatives. My initial requirements: 1) Stable sort. A non-stable sort is faster and useful for unique keys containers, but stable sort can be used initially in all flat containers until the non-stable version is implemented. 2) Externally supplied auxiliary memory with optionally no auxiliary memory at all. It seems that there are newer algorithms like Grailsort (https://github.com/Mrrl/GrailSort) or WikiSort (https://github.com/BonzaiThePenguin/WikiSort) that claim O(1) memory, even no auxiliary buffer, and key comparison and data exchanges with complexity O(n*log(n)). However I don't think those implementation correctly handle the basic exception guarantee or non-trivially copyable types. Reason: I want to avoid allocating short-lived temporary memory: if it's available I want to pass the extra capacity that flat containers' internal vector holds for future insertions. 3) Customization points (without ADL, which IMHO is not customizable enough). The sort algorithm should use a SortTraits template parameter for basic operations like "move", "swap", "initialized_move". E.g: template<class T> struct sort_traits { static? void move(T &from, T &to); static? void swap(T &l, T &r); static? void uninitialized_move(T &from, void *to); static? void destroy(T &from, void *to); }; I don't know if this trait should be stateful or not (static members). I could imagine the usefulness of a stateful implementation of sort_traits that could store a reference to an allocator so that some special "construct" version is used in some operations. Or just a version that counts the number of each operation to ease debugging. In any case, a stateless version would be enough for most cases. Reason: In Boost.Container, the idea is to use boost::move + boost::adl_move_swap in the initial implementation, maybe some destructive move implementation in a second iteration if Boost.Move implements it. In any case those operations should be customizable by the user, independently from the type to be sorted. This also avoids unnecessary dependencies in Boost.Sort. -> Dependencies: the implementation should only rely on Boost.Core, Boost.Config, maybe Boost.TypeTraits and no heavy STL dependencies (optionally). Currently Boost.Sort depends on Serialization for BOOST_STATIC_WARNING, but I think this is easily solvable, maybe this static assert utility should go to the core/utility library. Reason: Sort is a low-level algorithm that should avoid pulling unneeded dependencies to other boost libraries. * * * I don't know if other Boost libraries could benefit from this new stable_sort implementation. Maybe it's too special and I should try to write it myself in Boost.Container. I would love to hear comments and suggestions from sort experts, this might be a common need that could enrich the Boost.Sort library. Best, Ion

4 9

[regression] Tests for 'develop' not showing
by Edward Diener 23 Sep '15

23 Sep '15

Trying http://www.boost.org/development/tests/develop/developer/summary.html I get: "Error extracting file: The specified zipfile was not found."

4 4

Re: [boost] Error while building boost
by Roshan 22 Sep '15

22 Sep '15

Hi, This list is specific to the Boost.Compute library. This mail is probably meant for the main Boost mailing list. Forwarding you there. P.S. I'm not sure if the attachment is being forwarded properly, please check. On Tue, Sep 22, 2015 at 12:24 PM, <valnci89(a)gmail.com> wrote: > Hi, > > > I'm trying to install boost on my machine but its not building properly. > Attached is the output generated on running ./b2 install. > > > Commands used: > > ./bootstrap.sh --prefix=/usr/include/boost > > ./b2 install > > > Machine Info: > > OS: RHEL ppc64le > > Boost version: boost_1_59_0 > > > Let me know if any other info is required. > > > Please advice me on this issue. > > > Thanks, > > Valnci > -- Warm regards Roshan

1 0

[Container] interest in a flat_unordered_map
by Treb Connell 21 Sep '15

21 Sep '15

I'm hoping to port a flat hash map that I've written to boost. Since boost has a flat_map I think it'd be good to have a flat_unordered_map as well, especially since there's an opportunity to be much more efficient. The one I would like to use is based on the hash map used in Lua, which is a mix of Coalesced and Robin Hood hashes. I don't think there's a name that describes it yet unfortunately, but I describe it near the end of this post. *Performance (primary reason for use):* It uses memory and cache very effectively and ends up being *very fast*. It's hard to benchmark real world situations, but in inserting, finding, erasing, and iterating over a dictionary it was up to six orders of magnitude faster than VS2013's unordered_map. This isn't a totally fair test because the cache efficiency really shines. *Standards compliance:* Differences from std::unordered_map are widely the same differences as flat_map listed here <http://www.boost.org/doc/libs/1_59_0/doc/html/container/non_standard_contai…>. Also bucket related methods no longer apply, so will be removed. *That said there's one major standards compliance issue that I'm struggling with:* The most optimal implementation of iterators for this container *does not have constant time traversal*. The implementation is a vector with elements scattered across it. To increment an iterator I continue to increment the internal vector iterator until I hit a new element. In practice elements should be scattered evenly, and will be close to one another, but in the worst case this is N-1. Additional memory or logic could be added to make this O(1), but I don't think that trade is worth it. In my applications of unordered_map I rarely iterate, and would not want to penalize insert, find, or erase to make iteration faster. I could make a new concept for this, pay the cost for making it truly O(1), or *since the common case is not O(N) would it be okay to consider these bidirectional iterators*? *Implementation details:* You can see Lua's implementation here <http://www.lua.org/source/5.3/ltable.c.html>. The applicable logic is in and below *luaH_newkey, *comments are useful. It's primarily a Coalesced hash table, but differs in collision behavior. When a new key collides with an old key, we check to see if the old key is in it's "*main position"*. The main position is the index that the key hashes to. If it's not in it's main position that means that it previously collided and was displaced. Since this is the new keys main position, we displace again the current key, and place ourselves there. This drastically decreases chain length, and improves the load factor that the hash map can optimally reach. Sorry about long post, can go into additional details upon request. Thanks, Treb

6 7

A compile-time-counter code snippet for boost
by Igor V. Chesnokov 21 Sep '15

21 Sep '15

2 1

[serialization] bug in static_warning.hpp
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, In static_warning.hpp we have the following code (which, if I trust its name, should trigger a *warning*): #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; #define BOOST_STATIC_WARNING(B) BOOST_SERIALIZATION_BSW(B, __LINE__) Now, since, since there is no BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE defined in boost (there used to be one in static_assert.hpp) this thing will generate a typedef of the form: typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > $STATIC_WARNING_LINE$L BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; which is wrong. The MPI test are failing on that. Maybe BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE should be replaced with BOOST_ATTRIBUTE_UNUSED, but I am not sure what that macro is trying to achieve. Thks Alain

1 1

[locale] char conversion issue
by Alain Miniussi 21 Sep '15

21 Sep '15

Hi, My build is failing on message.cpp with: ../../../libs/locale/src/shared/message.cpp(439): error: invalid type conversion: "const wchar_t *" to "const char *" static_cast<char const *>(p), ^ detected during: [...] caused by code like: ================= template<typename CharType> struct hash_function { size_t operator()(message_key<CharType> const &msg) const { pj_winberger_hash::state_type state = pj_winberger_hash::initial_state; CharType const *p = msg.context(); if(*p != 0) { CharType const *e = p; while(*e) e++; state = pj_winberger_hash::update_state(state, static_cast<char const *>(p), static_cast<char const *>(e)); state = pj_winberger_hash::update_state(state,'\4'); } =================== Which looks like a legitimate error since that conversion does not seems t be covered by static_cast. This is on bot master and develop branch. The compiler is intel 16: [alainm@gurney build]$ icpc --version icpc (ICC) 16.0.0 20150815 Copyright (C) 1985-2015 Intel Corporation. All rights reserved. [alainm@gurney build]$ Regards Alain

2 1

[Compute] array support
by Fabian Bösch 19 Sep '15

19 Sep '15

Hi, I've been using Boost.Compute for some tests in the last couple of days. So far, it has proven very useful and I came to like it quite a bit. One thing I would add to it, though, is support for arrays when adapting your own classes for OpenCl through the Macro BOOST_COMPUTE_ADAPT_STRUCT. A simple overload would do the trick in my opinion: namespace boost { namespace compute { namespace detail { template<class Struct, class T> inline std::string adapt_struct_insert_member(T Struct::*, const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << ";\n"; return s.str(); } template<class Struct, class T, int N> inline std::string adapt_struct_insert_member(T (Struct::*)[N], const char *name) { std::stringstream s; s << " " << type_name<T>() << " " << name << "[" << N << "]" << ";\n"; return s.str(); } } // end detail namespace } // end compute namespace } // end boost namespace Hope something along this lines can be added, thanks, Fabian

2 1

[Coroutine] Back to the caller
by Mikhail Strelnikov 18 Sep '15

18 Sep '15

Hi, I have an issue after switching from Boost.Coroutine to Boost.Coroutine2 - nested coroutine switches to its creator - not to the caller. Here is the code - http://codepad.org/WGNs0N7F There are two coroutines (1st coroutine starts, makes some progress, then spawns 2nd coroutine. But 1st coroutine knows nothing about 2nd and does not communicate with it - main thread does). With Boost.Coroutine it works as expected and outputs: g1g1g1g1g2g1g2g1g2g1g2g1g2g1g2g1 leaving coroutine 1 g2g2g2g2 leaving coroutine 2 Here you can see that 1st coroutine exits but 2nd keeps working normally. And control from coroutines is returned back to the caller (g - caller, 1 and 2 - coroutines). But with Boost.Coroutine2 it outputs: g1g1g1g1g21g1g21g1g1g21 leaving coroutine 1 assertion failed : (false) && ("pull_coroutine is complete") Here you can see that when caller (g) calls 2nd coroutine, it does not yield back to caller, but instead switches to 1st coroutine ("g21" in output).Then it terminates on assert "pull_coroutine is complete". Is it a bug of Boost.Coroutine2? If not, how can I change this code to work equally for Boost.Coroutine and Boost.Coroutine2? Thanks! P.S. What is the reason of boost::coroutines2::coroutine<void>::pull_type not having default constructor? It is still possible to have an "empty" pull_type, but it is painful process.

2 6

Interest in algorithm for arithmetic mean of integers
by Matt Calabrese 17 Sep '15

17 Sep '15

AFAICT the only function for calculating arithmetic mean in boost is in the accumulators library and it's not really appropriate for integral types. In practice, properly calculating the mean for a range (especially a range that's only an input range but not a forward range) is surprisingly tricky to do in a way that avoids overflow and provides an exact result. I have a couple of solutions, including one that works for input ranges. Is this something that people would find useful? Is there a similar algorithm already implemented in boost that I'm not aware of? The approach I've taken yields an exact result as a mixed number and should work without overflow (assuming only that the range's size is able to be represented by its difference type). I believe the implementation that works for input ranges could theoretically be adapted to work with Boost.Accumulators, though I'm admittedly not too familiar with the library. -- -Matt Calabrese

5 10

integrating NaCl support into boost
by Konstantin Ivlev 17 Sep '15

17 Sep '15

Hi boost community, some introdution: NaCl (Google NativeClient, https://developer.chrome.com/native-client) - open-source technology authored by Google Inc. providing way to run native code inside web-browser in portable and secure manner. NaCl provides posix-like environment, and supports newlib and glibc standard libraries. currently NaCl is supported by Google Chrome web-browser, and range of applications and software libraries are ported to NaCl (include zlib, quake, etc.). how about integrating NaCl support patches into the boost main-line (trunk/master), I am talking about these NaCl ports patches from Google: https://chromium.googlesource.com/external/naclports/+/master/ports/boost (I actually have a bit more correct patches that allow to compile boost 1.59 for NaCl platforms, while Google patches are still for old version 1.55). some details about patches and which boost areas are covered by patches: - boost/config - common setup for NaCl - boost/cstdint - small change to expose boost::uintptr_t/boost::intptr_t for NaCl, similarly to how it was done to other compilers - buitin.jam and gcc.jam - introduced new os-name for NaCl, in order to properly setup threading libraries (NaCl has pthread but no rt, just like BSD) - boost/system/errorcode - oddball version of strerror_r (just like cygwin), also ENOTRECOVERABLE & EOWNERDEAD errno codes are not supported by PNaCl - boost/log/light_rw_mutex - not supported on NaCl note that boost build is incomplete - certain libraries are not (yet) ported to NaCl, because of platform-specific stuff like file/network I/O : - context - coroutine - coruutine2 - log - filesystem - test - timer - wave not sure if it's OK for start, or all boost libraries should be ported together in order to process further. I would be grateful to hear suggestion about how to process with it, e.g. which actions should I take to make it really happen. I personally suppose making boost to officially support more platforms will make boost even more popular and allow more developers to use it and port their applications to other platforms. I look forward to hearing from you soon. yours sincerely, Konstantin

4 5

Windows Phone and Visual Studio 2015
by Vladimir Prus 17 Sep '15

17 Sep '15

Folks, did anybody had success building Boost for Windows Phone using Visual Studio 2015 (aka 14.0)? We have Boost.Build code to do so, but it tries to find vcvarsphoneall.bat script, and some other similarly named scripts, that I don't seem to have anywhere, despite been able to build WP app from the IDE. Has anybody solved this? Thanks, Volodya

1 1

[predef] BOOST_ARCH_BITS_* feature request
by Antony Polukhin 16 Sep '15

16 Sep '15

Hi, It looks like for low-level programming following macro could be really useful: BOOST_ARCH_BITS_64 BOOST_ARCH_BITS_32 BOOST_ARCH_BITS_16 ? Predef also missing BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64. Boost.DLL really needs those macro for detecting bit's dependent elf/macho/pe structures layout. Is it possible to add them? -- Best regards, Antony Polukhin

4 4

Copyright-less licence references
by Gennadiy Rozental 16 Sep '15

16 Sep '15

Hi, I suggest we should drop "Copyright Joe Coder 20xx" from all our files. My reasons: * git/svn history provides much better copyright attribution. Each developer has a copyright on lines authored. As it is these copyright disclaimers are very frequently wrong. * I am never clear what this line really mean. Copyright Joe Coder 2010 - does this mean Joe has copyright up to 2010, starting 2010 or only in 2010? Should one keep updating these disclaimers every January? * For libraries which are maintained by multiple developers and/or which were moved from one maintainer to another maintainer - these disclaimers either wrong or pain to maintain. * these are just a clutter with no real value IMO we should just keep licence reference and that's it: // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) Gennadiy

12 38

Determining interest in container with efficient random access insert and erase
by Chris Clearwater 16 Sep '15

16 Sep '15

Greetings, I have written a library with the intention of submitting it to Boost.Container. My container implements O(log n) random access insert/erase and has a strong focus on performance while supporting the interfaces of the standard library sequence types. An example application would be the character buffer of a text editor. Useful links: - Source code: https://github.com/det/segmented_tree_seq - Documentation: http://det.github.io/segmented_tree_seq/ - Benchmarks: https://github.com/det/segmented_tree_seq/tree/benchmarks Any feedback is greatly appreciated.

14 28

BOOST_PP array extension proposal
by Antoine Leblanc 14 Sep '15

14 Sep '15

Hello to all of you! A few years ago, I've developped a small extension to BOOST_PP that adds a few functions to it. Namely: * ARRAY_CAT, which concatenates two BOOST_PP arrays; * ARRAY_LOWER_BOUND, which finds the index of the lower bound of an item in a given array of numerical values; * ARRAY_SORT, which sorts the given array of numerical values; * ARRAY_SORT_U, which sorts the given array and remove duplicates. I'm not sure it'd be worth adding to BOOST_PP; but if you think it might be, I'd be happy to submit a merge request. The code is rather small and can be browsed at https://github.com/nicuveo/TOOLS_PP Any suggestion or input is welcome. Thanks for your time! -- Antoine Leblanc

6 34

1.59 release notes don't mention new property_tree::json_parser
by Jonathan Wakely 14 Sep '15

14 Sep '15

The commit logs say: TL;DR: The new parser fixes long-standing bugs and has full Unicode support, but removes non-standard extensions of the old parser, which could break code: - String concatenation: the old parser concatenated adjacent string literals like C does. - Comments: the old parser supported C and C++-style comments. JSON doesn't allow comments. Removing support for comments did break something. Unfortunately there was no sign of this in the release notes, so I had to debug it the hard way (in code that swallowed the exception from the parser - gah!) and only found the commit message once I already knew what the problem was. </rant>

4 5

[type_traits] New version in master
by John Maddock 14 Sep '15

14 Sep '15

Just a quick heads up that the new version of type_traits is now in master, if there are any issues please do shout, John.

5 7

[type_traits] New version in master
by Glen Fernandes 14 Sep '15

14 Sep '15

Hi John, Any particular reason why 'is_trivially_default_constructible' was not provided as just the functionally-equivalent of 'has_trivial_default_constructor'? Glen

2 1

b2 headers failing
by Marcel Raad 13 Sep '15

13 Sep '15

Hi, when I try "b2 headers" on a fresh checkout of the develop branch, I get the following errors: C:/boost/tools/build/src/build\feature.jam:326: in validate-feature from module feature error: unknown feature "<segmented-stacks>" C:/boost/tools/build/src/build\feature.jam:360: in expand-subfeatures-aux from module feature C:/boost/tools/build/src/build\feature.jam:425: in feature.expand-subfeatures from module feature C:/boost/tools/build/src/build\property.jam:508: in property.translate from module property C:/boost/tools/build/src/build\property-set.jam:432: in property-set.create-from-user-input from module property-set C:/boost/tools/build/src/build\property-set.jam:484: in property-set.refine-from-user-input from module property-set C:/boost/tools/build/src/build\project.jam:700: in class(a)project-attributes.set from module object(project-attributes)@369 C:/boost/tools/build/src/build\project.jam:1099: in project from module project-rules libs\coroutine2\build\Jamfile.v2:26: in modules.load from module Jamfile<C:\boost\libs\coroutine2\build> C:/boost/tools/build/src/build\project.jam:325: in load-jamfile from module project C:/boost/tools/build/src/build\project.jam:64: in load from module project C:/boost/tools/build/src/build\project.jam:89: in load-used-projects from module project C:/boost/tools/build/src/build\project.jam:75: in load from module project C:/boost/tools/build/src/build\project.jam:145: in project.find from module project C:/boost/tools/build/src\build-system.jam:535: in load from module build-system C:\boost\tools\build\src/kernel\modules.jam:295: in import from module modules C:\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\boost\boost-build.jam:17: in module scope from module Does anyone know what's wrong here? Thanks, Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/b2-headers-failing-tp4680039.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

[AFIO] Formal review
by Jeremy Maitin-Shepard 12 Sep '15

12 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for > acceptance explicity. In its current state, Boost.AFIO should NOT be accepted into Boost. However, I am confident that Niall will be able to deliver a future version of AFIO that should be accepted into Boost after another review. There is a great need for more powerful and efficient file handling functionality in C++ than is provided by iostreams and Boost.Filesystem/Filesystem TS. I appreciate the enormous complexity of trying to define a multi-platform filesystem interface, and it is clear that Niall has done a ton of very valuable research on this topic. > 2. What is your evaluation of the design? A key strength of the design is that it provides a common interface for asynchronous operations regardless of whether they are internally implemented using Windows IOCP support, async IO on FreeBSD, or regular POSIX operations via a thread pool. Another key strength is that it exposes handle-based (i.e. *at), rather than path-based APIs where possible in order to minimize race conditions, which tend to be difficult or impossible to avoid completely with file system operations. I do have a number of concerns about several aspects of the design, however: Batch API: - It is not clear what, if any, purpose the batch API serves. The significant added complexity of using it would have to be justified by a significant performance advantage, but it is not at all clear that there is even any performance advantage at all. - I suggest removing it unless there is a strong argument otherwise. File handle API: - The file handle abstraction in AFIO is very heavy weight, involving a shared_ptr to a structure containing a whole bunch of fields in addition to the native file handle, including a mutex, numerous flags, the path used to open it, a pointer to a handle to the parent directory, a chrono time_point specifying the time the file was opened, the total number of bytes read, written, and written since last fsync using this file handle. - Because file handles are at the core of AFIO, it is critical that users precisely understand what this abstraction involves, and specifically how it differs from a native file handle. - I'd be much more comfortable with a much leaner abstraction, like a unique_handle type that just contains the bare native handle, and uses unique ownership semantics. The fat handles impose both computational/memory overhead as well as mental overhead on the programmer. I understand these extra fields are probably necessary to provide various functionality, particularly emulation of behavior provided by other operating systems, but it would be nicer to be able to opt-in to such functionality and only pay for it when needed. - At the very least, if these fat file handles are kept, a very strong argument needs to be given as a rationale. (Perhaps you have found the overhead to be negligible relative to the cost of the native file handle.) - It should be possible to construct an AFIO handle from a native file descriptor. - On POSIX, AFIO should support supplying platform-specific open flags, like O_NOATIME. - I'd much prefer native_handle() to return the actual appropriate native handle type for the platform, e.g. int on POSIX, rather than a void *. I'm guessing this is done in order to support alternative dispatchers, that aren't necessarily based on OS files at all, in the future, but perhaps a better way of doing this that doesn't require casting the void* to an int, can be found. Future-based API: - I agree with Thomas Heller regarding the Future-based API: - The implicit future.then built into the API should be eliminated. Instead, API functions should take a file handle directly. - future<T> should not implicitly store a file handle. The API functions that open a file can return a future to a file_handle. API functions that don't open a new file should just return a future to the actual result. Inconsistency in how operations are defined: - Some operations are methods of the dispatcher, some are methods of the file handle, and others are free functions. - I suggest that all file system operations be free functions, and take a dispatcher as an argument. Thread-local current dispatcher: - Some operations involve an explicitly specified dispatcher, others seem to obtain it from the file handle, and others default to a thread-local dispatcher that has been set. - Given that it is extremely likely for user code to execute from multiple threads given the nature of AFIO, relying on a thread-local current dispatcher seems very error prone. - I suggest that the thread-local current dispatcher be eliminated, and that the dispatcher always be specified explicitly to any API call that requires one. Directory handle cache: - A cache of open handles to directories is kept by AFIO by default. This is particularly problematic because (as is documented) it makes reading directory entries thread-unsafe by default. If this is to be kept, a very strong rationale needs to be given, and the behavior must be changed somehow to ensure that directory reading is reliable by default. Enumerate API: - The future-based API of async_enumerate seems to be unnecessarily complicated, due to the need to specify maxitems and deal with making repeated calls, and all of the copying and memory allocation required to return a std::vector of directory_entry. I suggest instead something like passing in a std::function<bool (expected<directory_entry> const &next)> callback (possibly replacing expected by the new name for your monad type). An empty next value means end of directory has been reached. Returning true means continue listing the directory, returning false means stop listing the directory. Miscellaneous comments: - Operations including rmdir, rmfile, symlink, rmsymlink (as well as async variants) that normally would not necessarily even operate on file handles, actually return a handle_ptr. Perhaps if on some platforms a handle has to be opened, then there could be a way for the user to specify that a handle is desired. Otherwise, it would make sense to just return void or std::future<void> equivalent for async variants. - The documentation notes that on MS Windows, DOS short names are not supported. I don't have much familiarity with Windows, but if programs generally accept DOS short names when a filename is required, then AFIO should probably support these names as well. - The documentation notes: "Don't do directory enumerations from an x86 binary on a x64 Windows system. This is due to a bug in Microsoft's WOW64 syscall translation layer which Microsoft have decided is wontfix. " Given that a major purpose of AFIO is to provide a portable abstraction that works around OS limitations, AFIO needs to support directory enumeration even in this case (e.g. by detecting WOW64 and using a synchronous call via a threadpool in that case). - It is noted that to do an asynchronous stat you have to use enumerate with an appropriate glob specified, but constructing such a glob may be non-trivial if the path contains characters that are interpreted specially by the glob syntax, and impossible to do in a race-free manner. - As a general matter, it is important to provide leanest possible API that offers the most flexibility to users, in order to avoid the case that users choose not to use the library despite it offering a lot of functionality that is useful to them, because of excessive overhead or insufficiently powerful interfaces. I often forgo use of Boost Filesystem and C++ iostreams for this reason. 3. What is your evaluation of the implementation? - I understand that Niall already intends to rewrite much of the implementation, making much of the current implementation irrelevant. - As has been noted by other reviewers, there are a bunch of #if 0 blocks, many undocumented. Some seem to contain work in progress, which might better be placed in a separate branch. Some contain debugging code, in which case it might be better to replace #if 0 with #ifdef BOOST_AFIO_DEBUG_XXX where XXX specifies the particular feature being debugged. That way it is self-documenting. Some seem to contain alternate implementations. Ideally these would also be guarded by a descriptive macro, and a unit test case be defined that tests it as well to make sure it is still meaningful. Otherwise #if 0 code tends to bitrot, which admittedly is not such a great problem if it is just for debugging anyway, but I'd say it is less than optimal. - The implementation might be better split up into multiple independent files. There are various independent facilities, like secded_ecc, that could be placed in a separate file. - Although this tends to be a problem with most Boost libraries, it would be nice if the compile times could be reduced, particularly when not in header-only mode. Some libraries like Boost Spirit have an interface inherently based on template metaprogramming, such that long compile times are pretty much unavoidable, but the Boost AFIO interface seems to be mostly non-template based, which suggests that it may be possible to get pretty good compile times. > 4. What is your evaluation of the documentation? - The extensive documentation about race guarantees is extremely useful. - I appreciate the in-depth examples. - Much more design rationale is needed. - The term "filing system" is used in place of the more common "file system", leading me to wonder if there is a difference in meaning. - Every instance where there is a platform-specific #ifdef in an example should be evaluated, so that you can figure out the appropriate platform-independent abstraction that could be added to AFIO in order to move that #ifdef into the library and out of user code. - There is an attempt to document differences in behavior on different platforms, but this is not done sufficiently. For example, it is stated that async_write requires that the destination region does not go off the end of the file, but on POSIX pwrite supports this just fine as a way to extend the file. I assume that this restriction applies to Windows only. - The semantics of the Batch API are not precisely documented, nor is any rationale given for it. For instance, I understand that the operations themselves cannot happen atomically, since that is not supported by operating systems, though this is not clearly stated. It is stated: "Once a batch of input ops has been verified at the point of entry as not errored, you are guaranteed that the batch is atomically scheduled as a whole, unless a failure to allocate memory occurs." Does this means that if the *_req object involves futures, it waits for all of them to be ready before launching any of the operations in the batch? Is that the purpose of the Batch API, to do a wait_all on all of the relevant futures, then to launch each operation? This issue goes away though if the Batch API is eliminated, as seems to make sense. - It would be useful to document for each operation which underlying system calls it invokes on each platform. - Many operations other than open (e.g. rmfile) take file_flags, but it is not specified which flags are supported. - References to historical versions of AFIO (prior to the review) should be removed from the main parts of the documentation, since they only distract from the useful information. This information could be kept in a different section at the end for the extra curious. - Formatting of the "description" in the Boost Quickbook format function documentation has some problems: the lack of line breaks between the general description, other notes, and the common note about the use of NT kernel paths make it difficult to read. > 5. What is your evaluation of the potential usefulness of the library? The library is potentially extremely useful. C++ and Boost iostreams and Boost/TS Filesystem provide only very limited functionality. The C library libuv is a close competitor but seems to offer less functionality and a less convenient API. For achieving similar functionality, the status quo in C++ is to rely on platform-specific C APIs that are much more cumbersome to use. > 6. Did you try to use the library? With what compiler? Did you have any problems? I tried some very simple usage of the library with GCC 5.2.0 on Linux. There were a few warnings (variable set but not used) with -Wall that would be best eliminated. - The error messages are not ideal: for instance, in the case that there was an error opening a file, this is the result: Dynamic exception type: boost::system::system_error std::exception::what: File '/home/jbms/tmp/afio-test/test.txt' not found [Host OS Error: No such file or directory (2) in '/home/jbms/tmp/boost.afio/include/boost/afio/v2/detail/impl/afio.ipp': async_io_handle_posix:805]: No such file or directory. Op was scheduled at: 1. 0x42fb4f: ./test (+0x2fb4f) : No such file or directory Some of this is only useful when debugging AFIO, some only useful when debugging the application, and there is a lot of redundancy, for instance the actual error "No such file or directory" is shown in 3 places. Ideally there would be a way to get a simple message along the lines of "Error opening file '/home/jbms/tmp/afio-test/test.txt': No such file or directory" that could be shown directly to the user. I tried to #define BOOST_AFIO_EXCEPTION_DISABLESOURCEINFO to see if that would make the error message better, but instead that seemed to trigger a bug: Dynamic exception type: std::logic_error std::exception::what: basic_string::_S_construct null not valid - A separate issue is that attempting to read a range that is not present in a file, something that the library should handle elegantly, leads to the program aborting immediately with an error message, rather than allowing the error to be handled: FATAL EXCEPTION: Failed to read all buffers 1. 0x40f0f4: ./test (+0xf0f4) terminate called after throwing an instance of 'std::runtime_error' what(): Failed to read all buffers zsh: abort (core dumped) ./test > 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I gave the library a fairly in-depth study, spending at least 8 hours in total. I looked at the documentation fairly thoroughly, looked through parts of the implementation, and tried running a couple small programs that use the library. > 8. Are you knowledgeable about the problem domain? I have a fair amount of experience with asynchronous programming in C++, and I have pretty extensive knowledge of the file system APIs on Linux. As a final note, I'd like to thank Niall for all of the work he has done to get the library this far. A powerful, elegant, cross-platform interface for file system operations is very much needed in C++, I really do want to see (a future version of) this library in Boost and use it myself.

11 32

Boost.Fiber mini-review September 4-13
by Nat Goodspeed 11 Sep '15

11 Sep '15

Hi all, The mini-review of Boost.Fiber by Oliver Kowalke begins today, Friday September 4th, and closes Sunday September 13th. It was reviewed in January 2014; the verdict at that time was "not in its present form." Since then Oliver has substantially improved documentation, performance, library customization and the underlying implementation, and is bringing the library back for mini-review. The substance of the library API remains the same, which is why a mini-review is appropriate. The Fiber library now requires a C++14-conforming compiler. I will monitor reviews and discussion on both the boost-users@ list and the boost@ developers' list. Please include at least "fiber" and "review" in your mail subject, e.g. by replying to this message. (Please reply to only ONE list, however.) Thank you for your interest and your feedback! ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses execution_context from Boost.Context; the classes in this library manage, schedule and, when needed, synchronize those contexts. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://olk.github.io/libs/fiber/doc/html/index.html git: https://github.com/olk/boost-fiber --------------------------------------------------- Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - 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? Nat Goodspeed Boost.Fiber Review Manager ________________________________

11 108

[fiber] on schedulers and wakeups
by Giovanni Deretta 11 Sep '15

11 Sep '15

Hi Oliver, I'm looking at the boost.fiber scheduling customization options. I have a few comments. My first concern is that scheduler is a global (per thread) property. This makes sense, but it limits its usability in libraries, unless the library completely owns a thread. It would be nice if schedulers where schedulable entities themselves, so that they could be nested (more at the end). Also the description of the scheduler interface does not specify any thread safety requirements. I assume that at least awakened must be thread safe as the scheduling might be caused by a signal coming from another thread. Any requirements should be specified properly. This leads to two additional points. First of all, there should be a way to retrieve the scheduler associated with a fiber: I haven't looked at the source, but the association must exist internally, otherwise cross thread scheduling wouldn't work. Second, there does not seem to be a way to allow signaled fibers to run in the context of the signaling thread. This seems an important optimization.I understand this is an explicit decision as currently it is not possible to portably migrate fibers, but the option should be left to the user if he knows it is safe in their setup. Possibly require 'awakened(fiber*x)' to call x->get_scheduler()->awakened(x) if it does not support running the fiber. My preference is to add a queryable boolean flag to each schedulable entity that states whether it is allowed to move from its scheduler (this makes a difference when you have multiple nested schedulers). Among other things this would also prevent work stealing. The flag would by default be set to prevent migration of course. Now, what do nested schedulers give you? In addition to composability, you can have the equivalent of an asio strand without explicit mutual exclusion. Let say you have a bunch of fibers that all access the same resource; you do not care where they run, as long as they never run concurrently. By binding all of them to the same scheduler, the guarantee is implicit. It should be possible to implement nested schedulers by having each fiber set the current scheduler pointer if it differs and store the previous one. On a scheduling event, if the current scheduler runs out of runnables, the signal/yield code would restore the previous scheduler and try again. Of course handling priorities and non strict fifo scheduling might be more complex. Note that the multi scheduler logic need to be implemented by Boost.Fiber itself. Finally, it might be possible (but I haven't tested this) to make fibers migrable on platforms where it normally isn't safe by allocating an actual thread for each one. The thread would be stopped as soon as it has been created, but a thread control block plush TLS entries would have been allocated. The existing context switch would need to be augmented with the ability to swap the thread context pointer. HTH, -- gpd

4 23

Critical. Help required. Boost.DLL Jamfile breaks testing with multiple toolsets
by Antony Polukhin 10 Sep '15

10 Sep '15

Hi, There's a big problem with Boost.DLL's Jamfile which I do not know how to fix. Introduction Tests of Boost.DLL create multiple *.so files and install them to a specified TEST_DIR path. Tests consume that TEST_DIR path and search for *.so in there: path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test ; project : source-location . : requirements ; { # our test lib for shared library tests lib test_library : test_library.cpp : <link>shared ; lib getting_started_library : ../example/getting_started_library.cpp : <link>shared ; install install-bin : test_library getting_started_library : <location>$(TEST_DIR) ; test-suite boostdll : [ run shared_library_load_test.cpp : $(TEST_DIR) : : <dependency>install-bin ] [ run shared_library_search_symbol_test.cpp : $(TEST_DIR) : : $(RDYNAMIC) <dependency>install-bin ] ; } The Problem If multiple toolsets specified, then `install-bin` target gets broken: cd libs/dll/test ../../../b2 toolset=gcc,clang error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxflags>-Wall -Wextra -pedantic -Wno-long-long <library>object(file-target)@3829 <library>object(file-target)@3862 <toolset-gcc:version>4.8 <toolset>gcc <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/gcc-4.8/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/gcc-4.8/debug/threading-multi error: - <library>object(file-target)@7264 <library>object(file-target)@7296 <toolset-clang:platform>linux <toolset-clang:version>3.4 <toolset>clang <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/filesystem/build/clang-linux-3.4/debug/threading-multi <xdll-path>/home/antoshkka/boost_maintain/boost/bin.v2/libs/system/build/clang-linux-3.4/debug/threading-multi Correct fix would be to embed into TEST_DIR the names of toolset and all other configuration flags. path-constant TEST_DIR : $(BOOST_ROOT)/bin.v2/libs/dll/test/$(FLAGS)/$(TOOLSET) ; The Question How to get the $(FLAGS) and $(TOOLSET) variables? If that requires writing rules or implies some other Boost.Build magic I'd really appreciate a pull request: any nontrivial modification to Jamfile takes months to apply and test because of my poor knowledge of Boost.Build. Jamfile: https://github.com/boostorg/dll/blob/develop/test/Jamfile.v2 Boost.DLL: https://github.com/boostorg/dll This issue is critical, because it breaks regression testing (see "[boost] [android][regression] bjam failed") -- Best regards, Antony Polukhin

5 9

Find All Paths
by Tom Skora 10 Sep '15

10 Sep '15

I have a list of vertices and using unidirectional edges, create multiple start and end paths starting from a start vertex. Ex. Vertices= 1,2,3,4,5, 6 Edges = (1,2), (2,3), (2,4), (2,5), and (5, 6) I would like to put in vertex 1 and have the following lists returned: 1,2,3 and 1,2, 4 and 1,2, 5, 6 What function can I use to return those lists Thanks Sent from my iPhone

1 0

[git] Stalled submodule updates?
by Rene Rivera 09 Sep '15

09 Sep '15

I was investigating why testing is currently broken.. And narrowed it down to the tools/build subproject on develop not being up to date with the current build submodule commit. Anyone know what has gone awry with the auto-updates of the super project? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[type_traits] Time to merge Version 2 to the master branch?
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi, Once Boost 1.59 is out, I'd like to suggest merging TypeTraits V2 to the master branch. It's a great job that will reduce boost library dependencies. Any chance this can happen soon? Best, Ion

4 5

[container] Implemented Polymorphic Memory Resources
by Ion Gaztañaga 09 Sep '15

09 Sep '15

Hi to all, In case anyone is interested, I just committed to the develop branch the implementation of the proposal "N3916 Polymorphic Memory Resources - r2" that was included in the TS "C++ Extensions for Library Fundamentals". The library continues to support C++03 compilers. It basically introduces in namespace boost::container::pmr and the path boost/container/pmr/: - memory_resource - synchronized_pool_resource - unsynchronized_pool_resource - monotonic_buffer_resource - polymorphic_allocator - resource_adaptor - new_delete_resource / null_memory_resource / get_default_resource / set_default_resource - Aliases for all containers, using the polymorphic_allocator. As default resource, new_delete_resource and null_memory_resource are required to be globals, they are implemented in the separately compiled boost.container library that was used to implement the DLMalloc-based extended allocator. It seems that many users dislike building Boost libraries, but I felt this was the correct way to implement it. We could change or make it optionally header-only if there is demand. To avoid dependencies to some users, I made sure that memory_resource and resource_adaptor, which don't depend on the global default memory resource, can be used without linking the library. Some logic was refactored from scoped_allocator_adaptor to avoid repeating the complicated template and preprocessor machinery in the polymorphic_allocator. I hope this does not cause any problem to scoped allocator users. Any suggestion or bug report is welcome. Best, Ion

5 8

Compiling with Clang 3.7.0 from windows
by Paul A. Bristow 09 Sep '15

09 Sep '15

I've downloaded the shiny new Clang 3.7 and added this to my user-config. # 64-bit version using clang # from http://llvm.org/releases/download.html : # version 3.7.0 : # Clang compiler .exe location #"C:/LLVM/bin/clang++.exe" # OK #"C:\\Program Files (x86)\\LLVM\\bin\\clang++.exe" # OK "C:\\Program Files\\LLVM\\bin\\clang++.exe" # : # options ; If I compile a simple hello world (no Boost library calls) program using the defaults (jam (using up-to-date Boost develop branch) it fails at the link complaining c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe which seems an odd message??? I:\modular-boost\libs\quickdox\example>b2 toolset=clang-3.7.0 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) ...found 22 targets... ...updating 4 targets... clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.obj clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-w64-windows-gnu Thread model: posix "C:\\Program Files\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-w64-windows-gnu -emit-obj -mrelax-all -disable-free -main-file-name quick_auto_dox_index.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -v -g -dwarf-column-info -coverage-file "I:\\modular-boost\\libs\\quickdox\\example\\..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto _dox_index.test\\clang-linux-3.7.0\\debug\\quick_auto_dox_index.obj" -resource-dir "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0" -D BOOST_ALL_NO_LIB=1 -I "..\\..\\.." -I "..\\include" -internal-isystem "c:\\mingw\\mingw32\\include\\c++" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\backward" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\mingw32\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\mingw32" -internal-isystem "c:\\mingw\\include\\c++\\4.8.1\\backward" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\mingw32" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include\\c++\\backward" -internal-isystem "C:\\Program Files\\LLVM\\bin\\..\\lib\\clang\\3.7.0\\include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include" -internal-isystem "c:\\mingw\\mingw32/sys-root/mingw/include" -internal-isystem "c:\\mingw\\lib\\gcc\\mingw32\\4.8.1\\include-fixed" -internal-isystem "c:\\mingw\\mingw32\\include" -internal-isystem "c:\\mingw\\include" -O0 -Wall -fdeprecated-macro -fdebug-compilation-dir "I:\\modular-boost\\libs\\quickdox\\example" -ferror-limit 19 -fmessage-length 0 -mstackrealign -fno-use-cxa-atexit -fno-inline -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o "..\\..\\..\\bin.v2\\libs\\quickdox\\example\\quick_auto_dox_index.test\\clang-linux-3.7.0\\debug\\q uick_auto_dox_index.obj" -x c++ quick_auto_dox_index.cpp clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-w64-windows-gnu ignoring nonexistent directory "c:\mingw\mingw32\include\c++" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\backward" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\mingw32\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\mingw32" ignoring nonexistent directory "c:\mingw\include\c++\4.8.1\backward" ignoring nonexistent directory "c:\mingw\mingw32/sys-root/mingw/include" ignoring nonexistent directory "c:\mingw\mingw32\include" #include "..." search starts here: #include <...> search starts here: ..\..\.. ..\include c:\mingw\lib\gcc\mingw32\4.8.1\include\c++ c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\mingw32 c:\mingw\lib\gcc\mingw32\4.8.1\include\c++\backward C:\Program Files\LLVM\bin\..\lib\clang\3.7.0\include c:\mingw\lib\gcc\mingw32\4.8.1\include c:\mingw\lib\gcc\mingw32\4.8.1\include-fixed c:\mingw\include End of search list. clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation) "C:\Program Files\LLVM\bin\clang++.exe" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.exe" -Wl,--start-group "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_ dox_index.obj" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g -m64 ...failed clang-linux.link ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug\quick_auto_d ox_index.exe... ...skipped <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.run for lack of <p..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang-linux-3.7.0\debug>quick_auto _dox_index.exe... ...failed updating 1 target... ...skipped 2 targets... ...updated 1 target... If I specify address-model=32, then it runs OK - but still says "64-bit : yes (cached)" which isn't what I would expect? I:\modular-boost\libs\quickdox\example>b2 -a toolset=clang-3.7.0 address-model=32 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) <<<<<<<<<<<<<<<<<<< ??????????????????? <snip> [Also example>b2 -a toolset=clang-3.7.0 address-model=64 fails to link as with no address-model specified (so default is 64 bit?)]. Suggestions? (Have I got the wrong version of mingw? I have others from ming64 - how do I specify to use those?) Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

6 26

Re: [boost] Common future base class (was Re: Boost.Fibermini-review September 4-13)
by Nat Goodspeed 07 Sep '15

07 Sep '15

On Sun, Sep 6, 2015 at 2:07 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: >> I've always found when_any much more interesting than when_all. Is it as >> trivial to implement with await as when_all? > Nod, I agree. However, I have not found a clever way to do that yet. On Mon, Sep 7, 2015 at 9:39 AM, Anthony Williams <anthony.ajw(a)gmail.com> wrote: > On 07/09/15 14:36, Agustín K-ballo Bergé wrote: >> On 9/7/2015 4:32 AM, Anthony Williams wrote: >>> On 03/09/15 16:47, Agustín K-ballo Bergé wrote: >>>> calling `set_value` on the same instance from different >>>> threads concurrently is expected to work, as in only one (unspecified) >>>> of them will actually make the shared state ready while all the others >>>> would throw `promise_already_satisfied`? >>> Yes, that was the intent. I've got an example that does exactly that in >>> chapter 8 of my book. >> Could you describe briefly what this example does? Is it just workers >> racing (in the good sense) to satisfy the promise? Or does serialization >> of set_xxx calls matter? > It's just workers racing to satisfy the promise. The first one to do so > sets the value, the rest get an exception. Seems like that could be the basis for a nice when_any?

2 1

Re: [boost] [Boost-users] Boost.Fiber mini-review September 4-13
by Vicente J. Botet Escriba 07 Sep '15

07 Sep '15

Le 06/09/15 02:21, Vicente J. Botet Escriba a écrit : > Le 05/09/15 16:27, Nat Goodspeed a écrit : >> On Fri, Sep 4, 2015 at 5:08 PM, Vicente J. Botet Escriba >> <vicente.botet(a)wanadoo.fr> wrote: >> >>> Le 04/09/15 20:37, Nat Goodspeed a écrit : >>>> On Fri, Sep 4, 2015 at 2:07 PM, Vicente J. Botet Escriba >>>> <vicente.botet(a)wanadoo.fr> wrote: >>>>> Please could you recall us what "not in the present form" meant as a >>>>> result >>>>> of the review and what has been done to overcome these issues? >>>> http://lists.boost.org/boost-announce/2014/01/0393.php >>>> >>>> I have not yet tried to address those point by point. >>> I don't understand then why are we doing the mini review now, before >>> you >>> check that any point has at least tried to be addressed. >> Sorry. How about these points: >> >> Performance: Oliver has not only worked to improve performance, he has >> included and documented performance tests you can run on your own >> hardware. > Great, I will check. > See below. >> Documentation: The documentation now contains several new sections >> explaining how to use the library for interesting/common use cases. >> New examples are presented and documented. > See below. >> >> API: The API has been aligned more closely with std::thread. C++14 is >> not only supported but required. Move-only callables are supported. >> Variadic parameters are supported. std::chrono is more generically >> supported. Channels now support value_pop(). fiber_group has been >> dropped. Migrating fibers between threads has been dropped. > See below. >> That said, of course, it is up to each reviewer to state for him- or >> herself whether s/he believes that the Fiber library should become >> part of Boost. In particular, regardless of what Oliver or I might >> synopsize, it is up to each previous reviewer to decide whether his >> January 2014 objections have been addressed. > To be clear, I believe that by respect to the reviewers you should > take the review summary you wrote and add a comment for each point. > > Best, > Vicente Hi again, In addition to my last request and in order to be able to write a review, I would like to know what exactly has been changed since the first review, what was expected after the review summary and what was removed, changed or added and what was the rationale. Best, Vicente

2 1

[android] New compilers: gcc-5.2 and clang-3.7
by Dmitry Moskalchuk 03 Sep '15

03 Sep '15

Hi all, We've added new compilers into CrystaX NDK recently: gcc-5.2 and clang-3.7 (old gcc-4.9 and clang-3.6 still there too). Testing results should appear on Boost regression page in a few days. Both compilers have fully passed our automatic tests, but you know, there still could be bugs, especially in such complicate projects. We're asking all maintainers of the Boost libraries look on that results and report us bugs (if any) to https://tracker.crystax.net/projects/ndk. The most important for us is catching regressions caused by new compilers compared to theirs previous versions. In case of such bugs, please don't add workarounds into Boost code; better report and let us fix them in CrystaX NDK. Thank you. -- Dmitry Moskalchuk

1 0

[Boost.AFIO] Formal Review
by Joel FALCOU 02 Sep '15

02 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? The topic of asynchronous file operation is very very important and quite critical in our days. Boost needs such a library but I fear *current* AFO is not there yet. I vote NO for its inclusion in Boost in its current form. > 2. What is your evaluation of the design? I think the intent are goods but there's some icky parts. The use of future and other asynchronous element in the API cudl be made more clear and easy. Thomas Heller made a compelling lsit of gotcha that shoudl be followed. Currently i had to fight against my habit of writing future absed code to get the stuff working. > 3. What is your evaluation of the implementation? Next to small scale issues like mammoth headers and liberal use of allocation in the implementation of some functions, I think the main culprit is to simplify the implementation by splitting the ABI stable part into another component. Also, the way asynchronous cmponents are used internally hould be aligned with the required fix on the public API. > 4. What is your evaluation of the documentation? The documentation is hard to follow and some 'simple example' are clearly not that simple. This should be the second major point of improvement. > 5. What is your evaluation of the potential usefulness of the library? THis kind of library is very useful and as I said, we need one with proper design and implementation. > 6. Did you try to use the library? Played around with the examle and the doc. > 7. How much effort did you put into your evaluation? Roughly 10-12 hours > 8. Are you knowledgeable about the problem domain? Not with async file I/O but I have a fair amount of experience in asynchronous computation and parallel programming in general. As a concluding note, I *really* want Niall to keep going on making AFIO the reference async file I/O library. Just take the needed time to reflect on the afformentionned PAI and implementation issues and remember that there is no rush to get there.

3 3

boost::python::make_setter(&X::y) no longer compiles
by Jonathan Wakely 02 Sep '15

02 Sep '15

This compiled with 1,58, it doesn't with 1.59: #include <boost/python.hpp> struct X { int y; }; int main() { boost::python::make_setter(&X::y); } Is this intentional? Is it documented somewhere? The examples in the docs still seem to use this form.

1 1

[atomic] Generalized read-modify-write operation
by Andrey Semashev 02 Sep '15

02 Sep '15

Hi, I was wondering is there would be interest in a generalized read-modify-write operation in Boost.Atomic. The idea is to have a atomic<T>::read_modify_write method that would take a function that would perform the modify on the atomic value. The interface could be roughly this: template< typename T > class atomic { public: // Returns the original value T read_modify_write(F modify, memory_order order = memory_order_seq_cst); }; Usage example: // Saturating increment atomic< int > a; a.read_modify_write([](int n) { return n < std::numeric_limits< int >::max() ? n + 1 : n; }); The implementation could synthesize a CAS loop around the modify function or (ideally) wrap it inside the LL/SC instructions, also in a loop. I believe, in order for this to work the modify function should meet certain requirements: 1. It must not use atomic operations (on this or other variables) or thread synchronization primitives. 2. It must not call functions that might involve context switching (e.g. syscalls, i/o). 3. It should be as small as possible and have the least possible working set (that is the number of accessed variables). 4. It must be prepared to be called multiple times. 5. It must be prepared to receive a value that has never been stored in the atomic variable. The first restriction is essential to avoid deadlocking in case of the emulated (lock-based) atomic<>. Thread synchronization primitives may possibly be using atomic ops internally, so are prohibited as well. The 2 and 3, besides just being something rational one would strive for anyway, are mostly targeted to allow to inject the function call inside the LL/SC pair. It is known that some architectures are very sensitive to what is happening between the LL and SC instructions, so accessing some memory from the modify function or switching the thread context will result in SC always failing and an infinite loop. The 5 would allow to make the first load non-atomic, which can be faster. The CAS or SC instruction will fail if the loaded value was inconsistent. I know there's probably no way to ensure that the function meets these requirements, and it is possible to get an infinite loop in runtime, so maybe always using a CAS loop would be a safer approach, even on an architecture with LL/SC instructions. My hope is that compilers will someday provide intrinsics for this and will be able to generate optimal code, when possible. Does this look interesting to anyone? Comments?

4 7

[AFIO] Formal review
by Giovanni Piero Deretta 02 Sep '15

02 Sep '15

Hi all, This is my review of boost.afio. In fact I have still more comments on the library, but this is taking already too long and I'm well past the review deadline, so I'm sending what I have. I'm hopefully going to post the second part in the next few days. 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicitly. No, not at this time. While the library is potentially quite useful, possibly to larger niche than expected to the author, I have many issues with both the documentation and the API itself, which would need to be resolved before acceptance. To be clear, this is not a conditional acceptance. I believe a full review is warranted to verify that the issues have been addressed. The author is obviously quite experienced in this area (or at least has done a lot of research), so I strongly encourage him to resubmit the library in the future as it has the potential to be be a great contribution to boost. 2. What is your evaluation of the design? My preference, but wouldn't require for acceptance, would be to use ASIO async protocol that leaves the choice of the completion notification strategy to the user . If the library wants all async functions to return futures, it should follow the standard future idioms. First of all, having futures which claim 'standard conformance' and then carry extra hidden error payload is unacceptable. Also functions should take handlers as parameters and not futures. The user should be responsible of explicitly 'then' chaining futures. The library should follow the standard semantics for handle types (i.e. single ownership move only wrappers system handles), and similarly for the future wrappers for such handles (i.e. future<handle>, not shared_future<handle>). Other reviewers have discussed these issues better than I could, so I won't expand further. The dispatcher should probably be called filesystem because that's what it is. The overridable per thread global dispatcher is evil. Functions should take a dispatcher explicitly (or through a handle_ptr) or use a static global dispatcher that represent the global filesystem. Does the library need to distinguish between files and symlinks at open time by calling differently named functions? I'll assume that's the case, but I would like to know the rationale. File, directory, symlink functions should be verbs and called open_file, open_directory, open_symlink. They should return differently typed handles (i.e. file_handle, dir_handle, sym_handle). As an aside, the handle types should have value semantics and be movable. To help generic code, rmdir, rmfile and rmsymbol should be unified under the same function name (rm, or better delete). The parameter type can be used to select the correct overload. Functions that return handles must do so explicitly (i.e. no implicit handle payload). The library should *never* cause the program to crash because of external causes (i.e. files and dirs disappearing or truncated, external locks taken, lock forcibly removed, up to and including disk failure). It is ok to abort on a failed internal consistency check, although it would be nice if the check+abort was encapsulated in an overridable macro (BOOST_AFIO_ASSERT maybe?). It is fine and even encouraged for the check be present even in release builds. The library *must* not suppose that every other program interacting with the filesystem is using AFIO. It is fine if the library were to give some additional guarantees (for example advisory locking becomes non-advisory), but these guarantees should be properly documented. For example, writes in append should be guaranteed atomic no matter what the program doing the writes is doing. In practice, this means that afio should document in detail the implementation of each operation for each backend for each operation so that a knowledgeable user can make the necessary inferences. In practice this seems already to be mostly the case. The documentation has a huge amount of notes on how the various FS and OSs differ and what are the different guarantees. AFIO should provide a standardised set of flags describing the various capabilities and a query interface, so that the inevitable different code paths do not need to be fs name dependent or, worse, #ifdef based. A good starting point for deciding which flags to expose, are the various FS tables scattered through the docs. 3. What is your evaluation of the implementation? I haven't had a chance to do an as in depth evaluation. Additionally, files with thousands of lines do not make it easy to read the code. The git repo contains both v1 and v2 subdirectories, and I'm not sure which one is the one actually under review (the docs say 1.5, not sure which one it is)' A few comments: Overuse of shared_ptr is in my experience code smell as the unclear ownership semantics lead to bugs down the line. The amount of ifdefs is staggering. Most of them are probably necessary, but the number of options that the library can be configured with certainly doesn't help.' It depends on external non-boost libraries, which it seems (but I can't be sure because of the layer of versioning macros) inject names outside the boost::afio namespace, which it shouldn't happen. With two spinlock acquisition per move, the lightweight future/modand seems anything but lightweight. The library should really use boost::future instead of rolling its own. The author should attempt to fold possible improvements directly into boost.thread. Similarly for any necessary improvements to Boost.Asio (for the WoW issue) and Boost.Filesysterm (for boost::path). The abstraction overhead seems excessive, especially for a library suposedly IO bound. The author should at least try to mach the performance of the naive openmp implementation. BTW, nonvolatile ram based storage will be becoming mainstream within the year, so the author might need to revisit very soon the relative cost of various operations. Random suggestions (feel free to ignore these): - look into non temporal stores to help with cache pollution. - have a libnfs backend + NFS over loopback for truly asynchronous filesystem operations (performance is probably going to atrocious). - experiment with the "O_NONBLOCK disk read" patches for the linux kernel. 4. What is your evaluation of the documentation? As noted by others, the documentation does not seem to be of boost standard quality; At times it feels more like a stream of consciousness; often irrelevant or less important information is presented before more important ones. Disquss Comments do not belong in the documentation. With JS disabled, some pictures are not shown, at least in the single page docs. I'm less bothered than others about the 'try AFIO online button'. In fact it would be nice to have such a button after each example (I'm not suggesting that the author should provide it though). Any reference to not-implemented features should removed and at best moved to a separate section at the end of the documentation. A common patters is: "" AFIO implements * A * B (not implemented) * C (not implemented) * D (not implemented)"" which is, honestly, a bit ridiculous. Similarly scattering references to preivious versions of the library all over the documentation is confusing. These should go to a separate history page and/or changelog. The misuse of Terms of Art ('monad' 'precondition') seem a bit worrying. At every occurrence of the term 'filing system' my brain trips. For a while I thought it meant something subtly different from the more common 'filesystem' or 'file system'. This could be just me, so feel free to ignore this unless others complain. The documentation often references C++1z coroutines, which as far as I understand are far from being standardisation ready. It would be better if examples using boost.coroutine, boost.context or even asio.coroutine were provided. ** Intro The first paragraph is a nice introduction, but it should mention prominently that AFIO helps prevents file system races. Move the sub points of bullet 8 to top level, instead deemphatize and sythetize the performance claims under a single bullet. Before claiming performance, describle what the library can do. Reduce any reference to APIBind to a single line (something 'AFIO can be used as a standalone library thanks to APIBind', details elsewhere; also do not claim that APIBind is a boost library). Remove any references to backends from this section. Totaly remove references to unimplemented backands. Supported compilers and platforms, jenkins and uni tests etc do not belong here. Neither do links to dispatch benchmarks. You might want to mention that it is a C++11 library written as part of the GSoC. A reference to ASIO might or might not belong here (No ASIO class or concept seem to be part of the interface). Remove the Batch section from the simple example. Also the rest should stand by itself, without the comments. About the example itself: I find it surprising that you call the results using verbs and operations using names. A better naming convention would be nice. Also in general please prefer type result = op(params); to type result(op(params)); at least when op is an important operation. The initialisation syntax together with the noun based naming convention makes it harder to parse examples. ** Cheat Sheet The frist few paragraphs are interesting, but should go after the table. The table as is not useful, other than an alternate index. I would expecte something like; function name, paramenters, result, very short description. I have no idea what the other columns of the table are trying to convey. The related functionality at the end does not belong here. ** Design Introduction and Rationale In this page I would expect to find an analysis of a generic afio async operation, why a certain interface was chosen, how futures help compose operation, how an operation is implemented internally. For every choice a discussion of the design tradeoff should be presented. Unfortunately, after an interesting "why did I write this library", the chapter loses itself. The version history does not belong here unless is used to justify design choices, but other than saying that previous versions where slower, no other information is conveyed. In particular, at this point of the documentation I would expect a thorough explanation of the concept of a FS race and the minimum guarantees given by the library with respect to file system races. Additionally as the library comes with its own future implementation, a detailed explanations of why boost::futures is not sufficient should be given. As an aside, the author claims that the library is completely lock free, and it would be wait free if not for the the use of spinlocks. This does not makes any sense as the use of spinlocks also make the library *not* lock free, unless the author is using a non-standard meaning for these terms (again see previous comment about misuse of Terms of Art). ** Write Ordering Constraint The explanation on how sync behaves like a barrier and the description of scheduling ordering and dependencies is very useful, and it should be a great starting point for a formal treatment of race freedom. The description of TripleGit is completely unnecessary and should be removed. ** Compilation This section is very confusing. Let' say I want the default (whatever it is) and do not define anything. I get this: After defining your build macros of choice, making latest AFIO available to your code is as simple as: #include "boost.afio/include/boost/afio.hpp" // latest version #include "boost.afio/include/boost/v1/afio.hpp" // specific version if being used standalone or if being used as part of Boost: #include "boost/afio.hpp" // latest version #include "boost/afio/v1/afio.hpp" // specific version I have no idea what any of the above means. ** Boost AFIO Installation into Boost Why is this information not part of the previous chapter? Any reference to non boost.afio should be dropped (except possibly to a link at the end to an external non boost distribution). I understand the the external build instructions are useful for reviewers, but they shouldn't have been part of the documentation under review. ** Supported compilers not much to say here other than, assuming AFIO is accepted, the table would be static and reflect the specific released version instead of trunk. ** Example 1 All references to the macro based versioning should be dropped. I have no idea why the example datastore has to return a monad<shared_ptr<iostream> >. The shared pointer is gratuitous, and for the ""simplest interface" errors can be communicated by exceptions As defined I would expect an interface like this for the simplest store: optional<std::string> read(std::string key) void write(std::string key, std::string content) or something like this for something more complex: some_special_container_range read(std::string key) template<class Range> void write(std::string& key, const Range& range); Possibly the author has in mind something different than a key value system. ** Example 2 Because the interface is non-ideal, it is hard to evaluate the next examples. Freedom from directory renames in nice, but I wouldn't count it very high in the list of requirements for an object store. A dispatcher is introduced, without explanation of what it is. The cheat-sheet mentioned it, but it should be described in more details here. The VM shenigans required to make something like utils::file_buffer_allocator<> work can have serious and hard to pinpoint performance and scalability considerations and shouldn't be presented as a performance win uncritically. The tradeoffs should be discussed. Also read mappings can defeat the point of async IO as the application threads will be subject to blocking page faults. Both previous comments are not trying to suggest that mmap is not useful, but it shouldn't be treated as a transparent optimisation as it can have application wide consequences well outside IO code. As far as I understand boost.afio leaves the choice to the client code and never does mmap behind its back; still the examples should present best practices. The example is too long and has too many distractions. The demonstration a streambuf can be implemented on top of afio is quite interesting, but should be relegated to a separate example. ** Example 3 BOOST_MONAD_PROPAGATE, in addition to being in the wrong namespace, is not documented anywhere (at least a search in the one page doc does not lead anywhere) and seems completely unnecessary. I guess it expands to either a return or a throw. In 'The problems with this naive design', the table does not have unit of measure. The information is interesting, although, without any comparison of durability, concurrency and atomicity guarantees of any of the solution, is hard to infer anything (not that I expect much from a NoSQL db...). ** Example 4 ' Linux is different from other operating systems in that you must explicitly request metadata updates to be sent to physical storage' I'm not an expert, but I thought this was true only for ext3/4 (and only with some, albeit default, mount options) and generally considered broken even by Linus himself. If that's the case might be important to point it out so users can choose other FSs. The atomic key replacement example is nice. Should the library provide pre-made recipes for these kind of uses? In The FS table, the first few column titles should be reworded so that all checkmarks mean that a positive feature is available and 'x'es mean a lack of it. 'This is a good example of where Intel's Hyperthreading can really penalise overall performance sometimes: filing systems tend to parallelise linearly to real CPU core count only.' Why is that the case? I would expect the exact opposite in fact. Are you sure the performance bottleneck is not somewhere else (TLB invalidation, cache misses, badly sized hash lock pools)? ** Example 5 The extent based and append behaviour are great. 'Any writes we make within a 4Kb boundary is probably safe'. 'Probably safe' is not something I want to see when implementing a DB. The example is probably way too complex for a tutorial, also the fact that is incomplete makes it hard to evaluate. ** Hello World Please remove the long comments from the examples. Either make them part of the surrounding explanation or footnotes. ** A less toy example The documentation sometimes claims that AFIO is either faster than dumb stream based IO and sometimes assert that it is slower. Please pick one and stick to it. Or better, do not make any performance claims outside a benchmark page. Performance should not be the biggest claim for AFIO anyway. The example uses stl_future which is not defined anywhere in the documentation as far as I can see. when_all_p(ihs).get(); should probably be when_all_p(ihs_req).get() In general, unless I've completely misunderstood the example, all the .get() calls impose synchronisation, which means that the parallel_concatenate is not as asynchronous as possible. Also it should really schedule handle closes at the end and return a future<void>. for(auto &i : ihs) lasts.push_back(dispatcher->depends(ohresize, i)); The meaning of dispatcher->depend on this code is not obvious at all. From mailing list discussions I assume that depend(future a, bufure b) is a.then([b] { return b; }), but what's the role of the dispatcher here is opaque. Even more surprisingly, a few lines below depend is called as a free function. Also, a few lines above this line is present: when_all_p(ohresize).get(); which should impose an explicit synchronisation, making the depend superfluous. This is the implementation I would like to see: using br = boost::range; auto async_size = [](auto&& name) { return async_info(name).then(auto&& info) { return info.size(); }; }; auto open =[](auto&& name) { reutrn asyn_open(name); }; auto get = [](auto&& future) { return future.get(); }; auto always = [](auto&& x) { return [x=std::move(x)] { return x;}; }; auto unwrap = [](auto&& fr) { std::vector<typename decltype(fr)::value_type> ret; copy_to(ret, mapped(fr, get)); return ret; } template<class PathRange> std::future<std::size> asyn_concat(std::path destname, PathRange&& srcnames) { auto sizes = when_all(br::mapped(srcnames, async_size)) .then(unwrap)).share(); auto total_size = sizes .then([](auto&& range) { return br::accumulate(range.get(), 0);; }); auto srcs_range = when_all(br::mapped(srcnames, open)); auto dest = when_all(async_open(destname), total_size) .then([](auto fdest, auto size ) [] { auto dest = fdest.get(); return async_truncate(dest, size).then(always(dest)); }); return wait_all(srcs_range, dest, fbuffers) .then([](auto&& fsrcs, auto && fdest, auto&& fsizes) { auto&& sizes = fsizes.get(); std::vector<handles> srcs = unwrap(fsrcs); std::vector<std::future<> > writes; struct ctx { off_t offset = 0; ssize_t len = 0; std::vector<char> buf = std::vector<char>(1024*4); }; std::vector<ctx> ctxs; ctx.reserve(src.size()); std::size_t off = 0; auto dest = make_unique(fdest.get()); for(int i = 0; i != src.size(); ++i) { ctxs.push_back({ off, sizes[i] ); off += sizes[i]; auto& ctx = ctxs.back(); auto read = [&ctx, &s = srcs[i]] { if (ctx.len < ctx.buffer.size()) ctx.buffer.resize(ctx.len); ctx.len -= ctx.buffer.size(); return async_read(s, ctx.buffer); }; auto write = [&ctx, &dst = dest.get()] { auto off = ctx.off; ctx.off += ctx.buffer.size(); return async_write(s, off, ctx.buffer); }; auto read_write = [&ctx, read, write](auto self){ if(ctx.len) return read().then(write).then(self); return make_ready_future(); }; writes.push_back(read_write(read_write)); } return wait_all(writes).then( [ctx=std::move(ctx), dst=std::move(dst), src=std::move(src)] { return wait_all( mapped(srd, [](auto&& s) { return async_close(s); }) .then([d = async_close(dst)] { return d; })) }); }); }; Note that everything is perfectly parallel and dependencies are minimal. Most operations use unique semantics except for 'sizes' where I didn't bother to do better. The lifetimes of buffers and handles in the read/writes are admittedly subtle, but not too much. Instead of creating N futures per file, I'm creating just a single one at a time. ** (all examples) Overall the examples are nice, the progression of additional features makes sense. The code should be cleaned up to remove superflous code. Comments should be removed and the code should be discussed in the prose (possibly referencing line numbers). I suggest that the strawman interface using iostream is removed. The lookups should simply return initially optional<string>, then future<string>. future<string> (or future<vector<char> >) of course does not work well for large buffers. You could return something like future<chunk>, where chunk has the following interface: struct chunk { const char * begin(); const char * end(); std::size_t size(); // an empty chunk means we are done future<chunk> next(); // invalidates this }; but the reality is that futures are not great for lazy streams. You could look into reactive streams, but that's another can of worms. For pure read/writes I suggest an asio-like interface which uses callbacks would be optimal and readily familiar to boost users. 5. What is your evaluation of the potential usefulness of the library? I had never had a chance to look at the library in the past, and my only impressions of it came by the many references and claims made by the author in the boost mailing list. In particular I was baffled by the author's claim that the ASIO callback interface is not adequate for file IO. I could not understand how async read/writes from a file could be so significantly different from socket io. Turns out that the actual I/O part is just a small part of the library, and the async part even less. The bulk of the library is about writing roboust filesystem manipulations. In my mind, where boost.filesystem is designed as a simple interface to file system operations for script-like programs, AFIO attempts to be the goto interface for robust applications. 6. Did you try to use the library? With what compiler? Did you have any problems? I didn't trey to compile or use the library. 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in depth study of the documentation. I didn't keep track of the hours, probably 10 or more. 8. Are you knowledgeable about the problem domain? Asynchronous File IO? No. Race free file IO? Neither, but had to deal with these kind of issues in the past. Something like AFIO might have been useful.

2 1

[afio] Formal review of Boost.AFIO
by Ahmed Charles 02 Sep '15

02 Sep '15

The formal review of the Boost.AFIO library starts, August 21st and ends on Monday August 31st. Boost.AFIO provides a portable API implementing synchronous and asynchronous race-free filesystem and scatter-gather file i/o. It requires a minimum of C++ 11. It has minimum dependencies on a Filesystem TS and a Networking TS implementation (e.g. Boost.Filesystem and Boost.ASIO). Backends are provided for the Windows NT kernel and POSIX. The utility of a portable library providing strong concurrent race guarantees about filesystem and file i/o can be seen in its tutorial where a transactional ACID key-value store is built from first principles. Boost.AFIO was brought to Boost as part of GSoC 2013 and Niall Douglas has continued to develop and improve the library since then, generating two internal implementation libraries Boost.APIBind and Boost.Monad which are expected to be separately brought for Boost review in 2016. The documentation can be found here: https://boostgsoc13.github.io/boost.afio/doc/html/afio.html The source code can be found here: https://github.com/BoostGSoC13/boost.afio/tree/boost-peer-review Online web compiler playpen can be found here: http://melpon.org/wandbox/permlink/DR8wCpu5Rl20GMdM? Please answer the following questions: 1. Should Boost.AFIO be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain?

30 191

[AFIO] Formal review
by Antony Polukhin 01 Sep '15

01 Sep '15

> 1. Should Boost.AFIO be accepted into Boost? This library must be in Boost, but not in it's current state. Some polishing required and some improvements. Dependent libraries must be accepted in Boost/dropped/documented and reviewed as part of AFIO. After that another review must be done. So it's NO for now. > 2. What is your evaluation of the design? NONBACTH operations seem right and good. Some simplification must be applied, by possibly removing some of the overloads and reducing amount of types visible to user (`handle_ptr`, `*_req`). BATCH operations do not seem right. They must be removed or their interface must be greatly reworked. afio::path must be hidden from user or filesystem::path must be used (I'm not 100% sure, but it looks like `\\?\` paths are OK to be in filesystem::path http://www.boost.org/doc/libs/1_59_0/libs/filesystem/doc/reference.html#lon… ). More functions for everyday use may be provided (async_copy for example) > 3. What is your evaluation of the implementation? Header files must be split into multiple smaller ones. Multiple memory allocations must be removed from library internals. Implementation must be polished. Recommendation: ABI stable part of AFIO may be moved in a separate git branch to untie the AFIO library developer's hands. In that case new version of AFIO may break the ABI without affecting users and older versions could be removed from sources. > 4. What is your evaluation of the documentation? That's one of the biggest problems of the library. Documentation is not structured and sometimes overcomplicated. Some notes for simplification: * "AFIO single page cheat sheet for the very impatient" -> "Getting started". Move table to the top of the page, replace the "Related types" column with "Boost.Filesystem sync alternative", replace numbers with checks/+/-. * Move the "Example mini-programs written using AFIO" chapter right after the "Getting started", rename chapter into "Tutorial", refactor second example to not use batch operations and to use only free standing functions. Third and fourth examples must be greatly simplified and probably split into smaller examples. * Move the content of "Step by step workshop building an AFIO-based key-value store" into the "Tutorial" after the previous examples, rename it into "Key-value store walkthrough", simplify and make shorter if possible * "Compilation" section must be somewhere around "Getting started" * Other docs must be after the "Getting Started," "Tutorial" and "Compilation" * "Reference" section must be refactored. All the overloads must be probably described and showed on a single page (all the overloads, including those that explicitly accept dispatcher) * Shorten and simplify the examples wherever possible. > 5. What is your evaluation of the potential usefulness of the library? Very very useful. > 6. Did you try to use the library? No. > 7. How much effort did you put into your evaluation? About 20 hours. > 8. Are you knowledgeable about the problem domain? I have a fair amount of experience with asynchronous programming in C++ and I have pretty extensive experience with designing interfaces for async operations. Have not dealt with async fiesystem operations before. -- Best regards, Antony Polukhin

2 1