April 2017 - Boost - lists.boost.org

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

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

[Safe Numerics] Review
by John Maddock 09 Jul '17

09 Jul '17

OK, here's my review of Robert's library. By way of something different, I've tried to not read the docs (though I ended up scanning them in the end) and just tried to use the library. Here's what I've found: 1) Using: safe<int>(-1) & 1 I get a hard assert failure at safe_base_operations.hpp:1373. I'm assuming that this is a mistake, and the usual error handlers should be called? Bitwise or has the same issue. More tests required ;) 2) I'm not sure if this is an msvc issue but in: constexpr safe_base operator~() The static assert is triggered for *unsigned types* and not for signed. Even if this is a compiler issue, it indicates a missing test case or two. 3) If I assign a float to an integer, then I get the error: "conversion of integer to float loses precision" which isn't quite what you meant to say. More particularly, for float conversions I would expect: * Conversion from a float holding an integer value that's within the range of the target type to always succeed. * Conversion from a float holding a non-integral value to conditionally succeed (with trunction) depending on the policy in effect. * Conversion *to* a float may also fail if the integer is outside the range of the float (no checking may be required if the number of bits in the integer is less than the number of bits in the float). 4) Is constexpr arithmetic supposed to be supported? I tried: constexpr boost::numeric::safe<int> j = 0; constexpr boost::numeric::safe<int> k = 3; constexpr boost::numeric::safe<int> l = j + k; Which generates an internal compiler error for msvc, and for gcc-5.3 I get: ../../../include/safe_base_operations.hpp:332:35: error: call to non-constexpr function ‘void boost::numeric::dispatch(const boost::numeric::checked_result<R>&) [with EP = boost::numeric::throw_exception; R = int]’ dispatch<exception_policy>(r); Similarly if I try to add a literal to a safe<int>. Again as the tests all pass, so I'm assuming they're missing constexpr tests? 5) What is the purpose of class safe_literal? constepxr initialization seems to work just fine without it? 6) In the docs, the example of using error handler dispatch is nonesense (top of page 41)? 7) Related to the above, I see the need to be able to define your own primitives which behave just like yours. The example I have is for bit-scan-left/right which has as precondition that the argument is non-zero, but there are other bit-fiddling operations (bit count etc) which some folks may require. A "cookbook" example would be good. 8) In the tests, you have an undocumented function "log" in the library. Not sure if this is intended to be part of the API or not, but IMO it's misnamed. ilog2 seems to a semi-standard name for this. 9) By way of testing the libraries performance I hooked it into the Millar-Rabin primality test in the multiprecision lib (test attached, it counts how many probable primes there are below 30000000), here are the times for msvc: Testing type unsigned: time = 17.6503 seconds count = 1857858 Testing type safe<unsigned>: time = 83.5055 seconds count = 1857858 Testing type 32-bit cpp_int: time = 36.9026 seconds count = 1857858 and for GCC-MINGW-5.3.0: Testing type unsigned: time = 17.1037 seconds count = 1857858 Testing type unsigned: time = 18.4377 seconds count = 1857858 Testing type unsigned: time = 21.0592 seconds count = 1857858 I'm surprised by the difference in times between msvc and gcc, also deeply impressed that there is effectively no performance penalty with GCC (I was expecting there should be some!) 10) I don't find the scope of the library over-broad, in fact I probably find it about right wrt the policies etc. 11) There were a few traits and such that it would be nice to have, the problem as ever, is what to call them and where to put them: * A trait for extracting the underlying type of a safe<> - use case for example where you enable_if a function on is_safe so don't have the template argument list to safe<>. * Do we need a function for extracting the underlying type of a safe<>? Or is casting to the underlying type optimal? Actually, maybe having a function would negate the need for the above trait, as we could just write 'auto x = mysafe.value();' ? * Do we need traits equivalent to is_signed/is_unsigned/make_signed/make_unsigned? My gut feeling is yes we do, the issue is what to call them, and where to put them - we're not allowed to specialize the type_traits versions (either boost or std), but we would need a central "one true trait" version that can be specialized by other libraries as well (Multiprecision for example). We've backed ourselves into a corner over this I fear! 12) When calling boost::integer::gcd/lcm the sub-optimal(?) non-binary versions are called for safe<> - you might want to look into seeing what traits need to be defined to ensure that the same version as the underlying type is called. Those are all the issues I can see for now... in conclusion, as for whether the library should be accepted, yes I believe it should be, modulo the issues above. Regards, John. --- This email has been checked for viruses by AVG. http://www.avg.com

4 14

[CallableTraits] Review results
by Louis Dionne 07 Jul '17

07 Jul '17

Dear Boost, I am pleased to announce that the CallableTraits library is CONDITIONALLY ACCEPTED into Boost. I counted the following formal reviews: - Bruno Dutra: Yes - Emil Dotchevski: Yes - John P. Fletcher: Yes - Klemens Morgenstern: Yes - Peter Dimov: Yes - Zach Laine: Yes The following people also participated to the review by providing informal feedback: - Edward Diener - Gavin Lambert - Niall Douglas - Paul Fultz II - Tim Song I also based my decision on previous experience I've had using the library, and some issues we faced in the Standard Committee where we could have used CallableTraits. I'd like to thank everyone who participated to the review for their feedback, and also Barrett Adair for his submission. The following lists the conditions for acceptance, and also summarizes the general feedback received during the review. GitHub issues are leveraged to make the tracking of these comments easier. Below, whenever I refer to #XYZ, the corresponding ticket can be found at https://github.com/badair/callable_traits/issues/XYZ To see all the issues that were discussed during the review, you can search for tickets labeled with `review` on GitHub (please allow some time for Barrett to update the new issues I just filed): https://github.com/badair/callable_traits/issues?page=1&q=+label%3Areview Conditions for acceptance ------------------------- The following are points that must be addressed for the library to be accepted. Once all of the associated GitHub issues are closed, I ask that the author post to this list with links to the closed issues. Unless major problems (having to do with the closed issues) are raised at that time, the library will be automatically accepted into Boost, no additional review required. - The library needs to clearly document the advantages of CallableTraits over FunctionTypes. Concrete examples must be given (at least one, preferably two). See #117. - The level of C++ conformance required for the whole library needs to be clearly stated in the documentation. Individual components should only document divergences from that base level of conformance. The current state of things is quite confusing for users. See #118. - The "algorithmic" parts of the library must be removed, since they are out of scope. This has already been partly done in issue #114, but the following algorithms must be discussed too (let's follow up in #114): + args_at + clear_args + pop_front_args + push_front_args + expand_args_right + expand_args_left - The lazy metafunctions and predicate traits should be SFINAE-friendly, just like the aliases are. I think this inconsistency is a big deal, enough to be a condition for acceptance. See #134. Summary of the feedback received -------------------------------- The following is a compilation of other points that were made during the review, but which are not requirements for acceptance. I trust, but do not require, that all of those points will be considered by the author: - There is a loss of information with the `args` metafunction. For example, `void(T)` and `void(T, ...)` both give the same result. See #132. - Consider adding a way of obtaining the parameter list of a function without the type of `*this`. See #133. - The documentation uses the terms of art "implementation defined" and "undefined behavior" incorrectly. See #103 and #131. - The non-reference documentation should present at least one real-world use case. See #116. - The library should handle top-level cv-qualifiers. See #106. - Consider supporting different calling conventions (e.g. `__cdecl`). See #102. - Consider adding a pre-C++17 implementation of `is_invocable` and friends. See #119. - The documentation should clearly state that the library can be used without the rest of Boost. See #99. - Consider combining `expand_args` and `args` into a single metafunction with a default "output" parameter of `std::tuple`. See #126. - Consider adding `make_fn` and `make_mem_fn` metafunctions to construct a signature from a return type and a tuple of the arguments. See #113. - Consider renaming some traits, like `is_reference_member`. See #108. - Reword some parts of the documentation that look odd due to the use of passive tense. See #105. - Consider adding a version of `apply_member_pointer` which carries cv-qualifiers. See #138. - Consider adding `remove_member_cv_ref` and `copy_member_cv_ref`. See #139. - Why does `qualified_parent_class_of` always returns a const& for PMDs? See #112. - Why does `qualified_parent_class_of` return a ref-qualified type even for unqualified PMFs? See #112. A few of my own comments: - Consider using alphabetical order in the table of contents of the reference. See #135. - Consider renaming `apply_member_pointer` to something like `make_member`. See #136. - Consider dropping the `parent_` in `parent_class_of`, or adding a note to justify the name. See #137. Again, thanks to everyone who participated in the review, and congratulations to Barrett for his work! Regards, Louis Dionne

2 3

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

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

[build] [config] check_target_builds and feature.subfeature composition
by Edward Diener 30 May '17

30 May '17

The Boost library config uses the check_target_builds rule to provide build time feature testing. Other Boost libraries use config checks in their own build and test jamfiles. I have found that this works reliably when a particular toolset is used in a normal manner. However when using the feature.subfeature and feature.compose rules to extend the toolset-version designation with a subfeature, such that the toolset designation now becomes toolset-version-subfeature, the use of the check_target_builds rule does not work as expected. In particular the individual check_target_builds rule results are put into a subdirectory based on the toolset-version and not based on the toolset-version-subfeature when toolset subfeature composition is used. I also suspect that the cached value reflects setup. This causes wrong results in tests where the toolset designation uses subfeatures, and a library's jamfile is using config and/or predef checks. As an example My toolset designation looks like: using gcc : 6.3 : some_path ; feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional composite propagated ; feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ; feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ; feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ; A library's test looks like: import ../../config/checks/config : requires ; run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ; If I run some some_test with toolset=gcc-6.3-c03, the config result for checking if forward list is supported is put into a subdirectory reflecting the toolset-version while the test result will be put into a subdirectory reflecting the toolset-version-subfeature. Subsequently if I run some_test with toolset=gcc-6.3-c11 the config result is taken from the subdirectory reflect the toolset-version even though whether the forward list is supported or not depends very much on the subfeature I am designating as part of the toolset. This naturally causes incorrect results for the test. Is this a known problem ? Is it a problem with Boost Build or is it a problem with how config uses the check_target_builds rule ? I have run into this problem extensively in my testing once I started to use the feature.subfeature ability of Boost Build.

5 9

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

23 May '17

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

2 2

[context] Windows x64 fiber local storage GS offset
by Elbert Mai 20 May '17

20 May '17

The Windows x64 implementation of Boost.Context saves fiber local storage from GS:[0x18]. For example, in jump_x86_64_ms_pe_masm.asm: ; load NT_TIB mov r10, gs:[030h] ; save fiber local storage mov rax, [r10+018h] mov [rsp+0b0h], rax However, this is the NT_TIB struct as defined in winnt.h typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; union { PVOID FiberData; DWORD Version; }; PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; This implies that fiber local storage is found in GS:[0x20], not GS:[0x18]. The Windows x86 implementation uses FS:[0x10], which is consistent with the NT_TIB struct. Am I missing something, or does Boost.Context save/restore fiber local storage at the wrong address in Windows x64?

3 3

[offtopic] Who has the power to create Trac accounts nowadays?
by Niall Douglas 19 May '17

19 May '17

Sorry for asking boost-dev, but had no reply on boost-steering. I've got some new GSoC mentors wanting to contribute to https://svn.boost.org/trac/boost/wiki/SoC2017 but they need a Trac login to do so. Who has that power, and can they grant me the power to create Trac accounts as this comes up every year? I'm ned14 on Boost Trac. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[dynamic_bitset] Comparison operators without assertions
by Pavel Kretov 18 May '17

18 May '17

Hi all. Looking through boost::dynamic_bitset code, I found a interesting inconsistency between its operator== and operator<. Namely, the first works well with bitsets of different size, while the second triggers an assertion: boost::dynamic_bitset<> a(std::string("111")), b(std::string("1110")); a == b; // false a < b; // Assertion `a.size() == b.size()' failed. This means that we cannot reliably use dynamic bitset within ordered containers like std::set or std::map. Since the standard library has distinct concepts of equality and equivalence (see [1]), it's fine to have different comparison behaviors in dynamic_bitset. However, as far as I can judge, equivalence is a metaphysically broader concept than equality, we shouldn't restrict it to bitsets of the same size only. So, the questions: 1. May I remove that assertion? (It won't be a breaking change, after all). 2. How about doing the same thing to bitwise operators, too? Instead of throwing an assertion if sizes don't match, it may be worth to generalize the operators definitions. I can see several possible schemes, but not all of them are consistent enough. 3. Shouldn't BOOST_ASSERT be used instead of the one from assert.h? ――― Pavel K. [1]: http://en.cppreference.com/w/cpp/concept/EqualityComparable

8 25

[Boost.Test] access to boost::unit_test::framework::master_test_suite().{argc, argv} outside from BOOST_TEST
by Olaf Peter 08 May '17

08 May '17

Hello, my test program uses boost.test datasets. I've wrote a filesystem loader for the input and expected data. Now I run into the problem, that boost::unit_test::framework::master_test_suite().{argc, argv} is only setup inside the tests self. My loader isn't a test case ... I can check it by using a simple mock, like struct app_mock { app_mock(); int const argc; char** const argv; }; app_mock::app_mock() : argc(boost::unit_test::framework::master_test_suite().argc) , argv(boost::unit_test::framework::master_test_suite().argv) { } BOOST_AUTO_TEST_CASE( app_mocker ) { app_mock app; std::cout << "Count = " << app.argc << '\n'; for(int i = 0; i != app.argc; i++) std::cout << "Arg = " << app.argv[i] << '\n'; } $ my_test -- my_args Count = 2 path/to/exe my_args these works, but as mentioned: dataset_loader::dataset_loader(fs::path const& path) { app_mock app; std::cout << "ARGC = " << boost::unit_test::framework::master_test_suite().argc << '\n'; read_files(path); } is always zero. How can I read the argc/argv values? Thanks, Olaf

2 4

[1.64] [ublas] Broken/regession due to Boost.Serialization changes
by Peppard 05 May '17

05 May '17

Hi, since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp gives an error like "no member named 'make_array' in namespace 'boost::serialization'", according to the official(?) test overview (http://www.boost.org/development/tests/master/developer/numeric-ublas.html) on a lot of systems. There have been discussions on this mailing list in Nov/Dec 2016 probably at least related to this ([boost] [serialization][ublas][test] failures in serialization causing regressions) and in Feb 2017 ([boost] [serialization][uBlas] Serialization still breaking anything that uses uBlas?), also there are several pull requests on GitHub, e.g. https://github.com/boostorg/ublas/pull/46. (I assume you are aware of this already, but I wonder why there was a release with a regression like this, maybe due to a maintainer missing? How are cases like these handled?) Thanks! (Sorry if this is a double post but the list address seemed to change from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)

3 2

GMane reflection of Boost mailing list messages
by Edward Diener 03 May '17

03 May '17

I am a user of GMane in regard to Boost mailing lists and it appears that GMane is no longer picking up Boost mailing list changes or allowing users to respond to mailing list posts through the corresponding GMane ng. Does anyone know how to rectify this situation ? I recall that Boost might have changed who was hosting the mailing lists and I am wondering if this is the reason that GMane no longer works with Boost mailing lists. The GMane website appears to be in transition, and all links for contacting anyone at GMane have been removed. I did try to contact Lars Magne Ingebrigtsen, who has been running GMane, but I do not know if this will produce any results.

4 9

Fwd: [clang] clang-cl expansion of macros
by degski 01 May '17

01 May '17

On 16 April 2016 at 17:58, Edward Diener <eldiener(a)tropicsoft.com> wrote: > What I strongly suspect will finally happen is that clang will not fix > these emulation problems because they are too tricky and numerous to do. > Instead they will probably declare that their emulation is good enough for > the majority of preprocessor constructs and that Boost PP, which pushes the > preprocessor to its limits, is not meant to work with their flawed VC++ > emulation. I hope I am wrong about that supposition, but having spent much > time in Boost PP and Boost VMD trying to workaround VC++ non-standard > preprocessor behavior I can envision that having to code "down" to that > behavior in numerous complicated instances will be too much time consuming > work for the clang developers who have chosen to work with VC++ > preprocessor emulation. > I've successfully built boost-1.64 with VC1410 (from the developer command prompt). Trying to use boost with a project using Clang 4.0.0 (both the LLVM and C2 backends) gives me the following PP error messages: 1>------ Rebuild All started: Project: test, Configuration: Debug x64 ------ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(59,7): error : too many arguments provided to function-like macro invocation 1> 2 1> ^ 1> z:\vc\x64\include\boost/preprocessor/facilities/expand.hpp(26,10): note: macro 'BOOST_PP_EXPAND_I' defined here 1> # define BOOST_PP_EXPAND_I(x) x 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected a qualified name after 'typename' 1> BOOST_MPL_AUX_NA_SPEC2( 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(166,44): note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC2' 1> #define BOOST_MPL_AUX_NA_SPEC2(i, j, name) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(64,11): note: expanded from macro '\ 1> 1> BOOST_MPL_AUX_NA_SPEC_MAIN' 1> BOOST_MPL_PP_PARAMS(i, typename T) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/preprocessor/params.hpp(58,11): note: expanded from macro 'BOOST_MPL_PP_PARAMS' 1> , BOOST_MPL_PP_AUX_PARAM_FUNC \ 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected ',' or '>' in template-parameter-list Up till now I was using a hacked boost-1.62. So in order to see what would happen, I also built boost-1.63. Apart from a small change in type_with_alignment.hpp (adding a ckeck for _MSC_VER not to exist if __clang__ does exist in line 87), boost-1.63 compiles without a problem (no specific (relevant to the emulation) command line parameters). Is there a macro I should define or is there something else I should set/do in order to use boost-1.64 with Clang 4.0.0 on windows? Any other suggestions? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 13

[review] Review of PolyCollection will start in a few days
by Ion Gaztañaga 30 Apr '17

30 Apr '17

Dear Boost community, The formal review of Joaquín M López Muñoz's PolyCollection library will start on Wednesday, May 3rd and ends on May 12th. This library implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. If you are interested, you can start preparing your review with the following information: Repositories: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html See you on Wednesday! Ion

1 0

[integer][math]Heads up on revised gcd/lcm code
by John Maddock 30 Apr '17

30 Apr '17

First some history.... Some time ago, the old gcd/lcm code was moved from Boost.Math to Boost.Integer as a means of reducing inter-library dependencies. Unfortunately a number of tasks were never completed: the docs weren't added to Boost.Integer, and the Boost.Math code never got updated to redirect to the moved headers. Fast forward a couple of years and when Jeremy Murphy contributed a new version of the gcd/lcm code as part of supporting polynomial gcd, and since I'd completely forgotten about the move, this got integrated into Boost.Math leaving us with two divergent versions. As part of sorting this mess out, I've now pushed to Boost.Integer a "best of both" version of this code, so far as I can tell, all dependent libraries are unaffected by the change, though I do need to do some more work on supporting obsolete compilers I no longer have access to. The main enhancements are: * New mixed binary/Euclid algorithm added, this seems to be the best performing algorithm in most cases, and is now the default for most integer types (performance is deeply dependent on the input though, so your mileage may vary). * In addition to integer and rational support, polynomial gcd is now supported via boost::math::polynomial. * There are new range based gcd-lcm algorithms for calculating the gcd/lcm of all the values in an iterator range, this is primarily for polynomial gcd support. * There are new variadic overloads of gcd/lcm for calculating gcd/lcm over more than 2 values. * The gcd/lcm functions are now constexpr in C++14 land, this means that the old compile time calculation traits classes are rendered obsolete for current compilers. * The gcd/lcm functions are now noexcept where appropriate. * Compiler intrinsics are now used speed up binary-gcd steps where possible, sadly this is incompatible with constexpr support since the intrinsics aren't yet constexpr :( Please do let me know if you find any snags, best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 17

Boost MultiIndex slow mass insertion
by miticodonati＠libero.it 29 Apr '17

29 Apr '17

I have the following structure: typedef boost::multi_index_container< MyClass, boost::multi_index::indexed_by< boost::multi_index::hashed_unique<boost::multi_index::member<MyClass, int, &MyClass::label>>, boost::multi_index::ordered_non_unique<boost::multi_index::member<MyClass, double, &MyClass::dist>> > > MyClassSet; If i populate it in a loop: MyClassSet all: for (int y = 0; y < input.rows; ++y) { MyClass c; // .... all.insert(c); } the insertion time is quite slow. It probably need to continuously re-order the underlying implementation. Anyway i would expect that populating it with a single call it would be faster (e.g. sorting the whole set only at the end). Example: std::vector<MyClass> vec; // ... MyClassSet all(vec.begin(), vec.end()); BUT... the times are almost equal. My question is: is this intended behaviour? Is there a faster way to mass populate the container (e.g. not enforcing the invariants/orderings at each 'insert')?

3 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[quickbook] diagnosing a missing [endsect]?
by Peter Dimov 28 Apr '17

28 Apr '17

I just noticed a missing [endsect] in the middle of one of the .qbk files in the Core documentation. The main .qbk file contains [include addressof.qbk] [include checked_delete.qbk] [include demangle.qbk] [include enable_if.qbk] [include explicit_operator_bool.qbk] [include ignore_unused.qbk] [include is_same.qbk] [include lightweight_test.qbk] [include no_exceptions_support.qbk] [include noncopyable.qbk] [include null_deleter.qbk] [include ref.qbk] [include scoped_enum.qbk] [include swap.qbk] [include typeinfo.qbk] and in the middle of lightweight_test.qbk an [endsect] was missing. The end result of it was that the following includes went into the [section] opened in lightweight_test.qbk, as subsections. This wasn't noticeable from a cursory look so it went unnoticed for a while. Is it worth diagnosing this problem in some way? We probably can't disallow unbalanced sections in an [include], but this could be a warning? (If someone pays it any attention, of course.) Presumably, at the end of the file there'll be a [section] left open? This could be made an error so it'd be harder to miss.

4 23

[core] [noncopyable] Add nonmoveable?
by Viktor Sehr 27 Apr '17

27 Apr '17

In addition to noncopyable, I sometimes want to force classes to be nonmoveable as well (mainly node-type classes in tree structures which other classes point to). Therefore I'd suggest adding a cousin to noncopyable; boost::nonmoveable which simply prevents an instance to be nonmoveable (as well as noncopyable). Note; even due the delete modifier were added in C++11 I still think inheriting boost:noncopyable\nonmoveable syntactically nicer than manually marking the copy\move constructors\assignment operators delete. /Viktor Sehr

4 8

[1.64][python] not building for Visual x64
by Raffi Enficiaud 27 Apr '17

27 Apr '17

Hi, I have some trouble building boost.python for the freshly released boost 1.64: there is no boost.python binary generated, and "bin.v2/libs" does not contain any folder named "python". Maybe related: the machine has python2.7 and 3.4 installed. The command for building: b2 toolset=msvc-14.0 --layout=versioned --build-type=complete --without-log -j 4 address-model=64 threading=multi runtime-link=shared The same command was used for 1.63 with no issue. What am I missing? Let me know if this is a chair-to-keyboard problem. Best, Raffi PS: logs of the second run attached (the number of messages for the first run is flooding the console).

2 2

[stacktrace] Two days remaining before review ends
by Niall Douglas 27 Apr '17

27 Apr '17

Current summary of votes cast so far: * Peter Dimov: Unconditional acceptance * Vladimir Batov: Unconditional acceptance Am I missing any? If you are going to make a review and a recommendation, please do so soon. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 9

[release] Epic fail: Numeric cast in 1.64 does not match trunk
by Antony Polukhin 26 Apr '17

26 Apr '17

Hello, File https://github.com/boostorg/numeric_conversion/blob/master/include/boost/nu… does not match the one in release 1.64 That file was fixed and merged to master a long time ago, however boost_1_64_0.7z archive still has on outdated version (one with std::unary_function). This looks like an issue within some release scripts. Issue was noted here: https://svn.boost.org/trac/boost/ticket/12972 -- Best regards, Antony Polukhin

4 4

How to contribute??
by Saurabh Singh 25 Apr '17

25 Apr '17

Hey, This is Saurabh from New Delhi, India. I want to contribute to Boost and help you guys in fixing bugs. Can you please help me to get started in doing so. Thanks

3 2

[release] 1.65.0 open for merging
by Rene Rivera 24 Apr '17

24 Apr '17

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 3

[context] - Boost.Context fails to build -> Call of overloaded 'callcc(...) is ambiguous'
by Carlos Ferreira 24 Apr '17

24 Apr '17

I was trying to compile Boost 1.64.0 for OpenWRT when the build failed for Arm Cortex A7 (Raspberry Pi 2) using Gcc 5.2 with Musl 1.1.16. The build output with the error follows. Any ideas on what it could be ? gcc.compile.c++ bin.v2/libs/fiber/build/gcc-arm/release/abi-aapcs/boost.locale.iconv-on/boost.locale.posix-off/link-static/threading-multi/context.o libs/fiber/src/context.cpp: In constructor 'boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)': libs/fiber/src/context.cpp:236:14: error: call of overloaded 'callcc(const std::allocator_arg_t&, const boost::context::preallocated&, const default_stack&, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>)' is ambiguous }); ^ In file included from ./boost/fiber/context.hpp:28:0, from libs/fiber/src/context.cpp:7: ./boost/context/continuation.hpp:469:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::preallocated; Fn = const boost::context::basic_fixedsize_stack<boost::context::stack_traits>&; Arg = {boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}] callcc( std::allocator_arg_t, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:483:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&, Arg ...) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>; Arg = {}] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn, Arg ... arg) { ^ ./boost/context/continuation.hpp:514:1: note: candidate: boost::context::continuation boost::context::callcc(std::allocator_arg_t, boost::context::preallocated, StackAlloc, Fn&&) [with StackAlloc = boost::context::basic_fixedsize_stack<boost::context::stack_traits>; Fn = boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>] callcc( std::allocator_arg_t, preallocated palloc, StackAlloc salloc, Fn && fn) { ^ ./boost/context/continuation.hpp:457:1: note: candidate: boost::context::continuation boost::context::callcc(Fn&&, Arg ...) [with Fn = const std::allocator_arg_t&; Arg = {boost::context::preallocated, boost::context::basic_fixedsize_stack<boost::context::stack_traits>, boost::fibers::context::context(boost::fibers::dispatcher_context_t, const boost::context::preallocated&, const default_stack&, boost::fibers::scheduler*)::<lambda(boost::context::continuation&&)>}; <template-parameter-1-3> = void] callcc( Fn && fn, Arg ... arg) { ^ -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

2 2

Supporting boost 1.64 for Visual Studio 2017
by Evgen8 23 Apr '17

23 Apr '17

The "NuGet" system indicates that BC 2017 is supported. *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: Win32, x64.* But attempts to use this package end with nothing. Regardless of how I install the "boost_locale" - do I get the same result manually or using "NuGet"? Attempts to install it on another machine ran out the same. Is this a bug? /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::system_category(void)" (?system_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(localization_backend.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(lcid.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>libboost_locale-vc141-mt-1_64.lib(date_time.obj) : error LNK2001: unresolved external symbol "class boost::system::error_category const & __cdecl boost::system::generic_category(void)" (?generic_category@system@boost@@YAABVerror_category@12@XZ) 1>E:\Yandex.Disk\Projects\OS\Release\Devs.exe : fatal error LNK1120: 2 unresolved externals/ -- View this message in context: http://boost.2283326.n4.nabble.com/Supporting-boost-1-64-for-Visual-Studio-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Re: [boost] Supporting boost 1.64 for Visual Studio 2017
by Andrey Semashev 22 Apr '17

22 Apr '17

On 04/23/17 00:11, Nadtochiy Evgeniy wrote: > 22.04.2017, 21:07, "Andrey Semashev" <andrey.semashev(a)gmail.com>: >> >> On 04/22/17 20:29, Evgen8 via Boost wrote: >> >> The "NuGet" system indicates that BC 2017 is supported. >> *boost_locale-vc141. Compiler: Visual Studio 2017. Platforms: >> Win32, x64.* >> But attempts to use this package end with nothing. Regardless of >> how I >> install the "boost_locale" - do I get the same result manually or >> using >> "NuGet"? Attempts to install it on another machine ran out the >> same. Is this >> a bug? >> >> /1>libboost_locale-vc141-mt-1_64.lib(generator.obj) : error LNK2001: >> unresolved external symbol "class boost::system::error_category >> const & >> __cdecl boost::system::system_category(void)" >> >> >> The missing symbols are from Boost.System. Since you're linking static >> libraries, you'll have to specify Boost.Locale dependencies manually to >> link with in your project. >> > How can i do this? There was always enough installation with NuGet... I don't know what NuGet is or how it works, but the libraries to link with are typically specified in VS project settings (look for the linker parameters tab). PS: Also, please, don't top post.

1 0

[1.64][process] Windows line endings in headers
by Andrey Semashev 22 Apr '17

22 Apr '17

Hi, I can see some of the headers in Boost.Process (for example, boost/process/cmd.hpp, boost/process/env.hpp) contain Windows line endings. Regarding 1.64, Windows line endings are also present in the .tar.bz2 package, which is supposed to be targeted for POSIX systems. 1. Could Windows line endings be removed in git? 2. Could the release procedures be updated to ensure that foreign line endings don't creep into the released packages? I understand that 1.64 has sailed, but I think at least a note (preferably, with a patch) would be appropriate in the release notes.

7 11

[Stacktrace] Second review begins today 17th Mar ends 26th Mar
by Niall Douglas 22 Apr '17

22 Apr '17

I am pleased to announce the second review of the proposed Boost.Stacktrace library running from today until Sunday 26th. Stacktrace is an optionally header-only library providing multiple implementation backends. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= This is a second review of this library with many changes implemented in response to feedback from the previous review. My previous review report can be found at http://lists.boost.org/boost-announce/2017/01/0486.php where I made the following conditions for acceptance: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. Antony hasn't entirely met my conditions, hence this second review. He has instead implemented this changelog: * Reimplemented boost::stacktrace::basic_stacktrace class to accept allocators and to have a small size * Added outputting of the path to the binary object into the stacktrace, when source location is not available * Allowed to use `libbacktrace` - a defacto standard for GCC/CLANG backtracing that does not fork and has a permissive license * Optimized stacktrace and frames ostreaming * Removed backends and made the default tracing to have only platform basic functionality. Added macros to enable additional functionality. * Fixed (theoretically) MinGW compilation * Added functions for async-safe dumping into memory or descriptor * Changed signal handling example to be async-signal-safe * Allowed users to choose how many frames to skip during stack capture * Removed `boost::stacktrace::stacktrace` functions and other internals from printed stack traces * Updated docs: * examples now use Boost.Exception * removed all the references to "backend" * reduced macro count * "Build, Macros and Backends" section was rewritten and became "Configuration and Build" * added note that library is C++03 * added examples on storing traces into shared memory * updated all the human readable dumps It is up to the Boost community as to whether this revised library is now acceptable without any conditions, or with conditions. Reviews should be submitted to the developer list (boost_at_[hidden]), preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

9 44

Locating Visual Studio 2017 on disk
by Andrew Pardoe 20 Apr '17

20 Apr '17

Folks, We had a number of conversations about the fact that VS 2017 could be installed in any location, or multiple locations, and no longer created a registry key pointing to an install location. There's also the problem that an installation of VS 2017 may or may not contain C++ tools (as was the case with VS 2015.) The solution proposed by the VS team-creating a tool called VSWhere-was inadequate for some scenarios such as Boost's because it would have required either caching a binary in your source enlistment or compiling code to locate the compiler. A number of people on this list asked for a more straightforward solution. I'm happy to tell you that your feedback was heard. We're going to start shipping the VSWhere tool in a known location on any machine that has VS 2017. More details can be found in this blog post: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed… This doesn't fix the problem for all the versions of VS 2017 that are installed already. And this doesn't help our version numbers to make any more sense (although I'm pushing to fix that as well.) But at least in the future you'll be able to locate VS installs from a scripted environment. Thanks for being loud and reaching out to us. As always, I'm happy to help you with any issues you might have with MSVC-just ask. Andrew Pardoe MSVC compiler & tools

1 0

[stacktrace] Please for into boostorg repo
by Antony Polukhin 20 Apr '17

20 Apr '17

Hi, Stacktrace library was accepted into the Boost http://www.boost.org/community/review_schedule.html Please fork the repo https://github.com/apolukhin/stacktrace into boostorg and give me admin rights to that repo. -- Best regards, Antony Polukhin

2 4

Boost Library Incubator Statistics
by Robert Ramey 20 Apr '17

20 Apr '17

In the course of updating the Boost Library Incubator website, I gathered some summary statistics which some might find interesting. 40 Number of libraries submitted 2 libraries not accepted into the incubator of lack docs, test, etc. 11 libraries reviews by boost 9 accepted 2 rejected All in all, I'm thinking these numbers aren't too bad for boost and the incubator. I would like to see more submissions - but the submissions we've received seem to be better than average quality and worthy of consideration. Hopefully this has made the review process more efficient. A couple of libraries have also been accepted (and rejected) without having been placed in the incubator. The number is small. I think this validates the incubator as useful, but not necessary and libraries authors should continue to be encouraged, but not required, to submit library candidates to the incubator. Other than the above, I'm not going to try to draw any conclusions from the above admittedly anecdotal data. I would also remind boosters that if you're logged into the incubator, you can display statistics on viewership for a particular library by using the "Display Statistics" button on the library page. This is a crude but someone engaging way to get an idea of how many people have looked at the library page. The attached shows visits to the safe numerics library page in the last 90 days. Robert Ramey

3 5

List-Id mail header
by Christoph Ludwig 20 Apr '17

20 Apr '17

Hi, starting yesterday, the List-Id header in the mails I get from the Boost mailing list changed. It used to be: List-Id: Boost developers' mailing list <boost.lists.boost.org> Now it is: List-Id: Boost developers' mailing list <boost.wowbagger.crest.iu.edu> Due to this change, the mail filter I have used for years fails to identify the messages as boost mailing list traffic. Therefore, the messages end up in my regular inbox instead of the dedicated folder I have for the mailing list. Of course, I can easily update my mail filter, that's no big deal. I just want to know: Did I miss an announcement, was this change intended? Will the List-Id use the wowbagger identifier from now on? Cheers, Christoph

2 1

[release] Boost 1.64.0
by Rene Rivera 20 Apr '17

20 Apr '17

Release 1.64.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/history/version_1_64_0.html> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.64.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[release] Boost 1.64.0 Release Candidate 1
by Rene Rivera 19 Apr '17

19 Apr '17

The release candidates for the 1.64.0 release are now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.rc.1/> The SHA256 checksums are as follows: 49c6abfeb5b480f6a86119c0d57235966b4690ee6ff9e6401ee868244808d155 boost_1_64_0_rc1.7z 7bcc5caace97baa948931d712ea5f37038dbb1c5d89b43ad4def4ed7cb683332 boost_1_64_0_rc1.tar.bz2 0445c22a5ef3bd69f5dfb48354978421a85ab395254a26b1ffb0aa1bfd63a108 boost_1_64_0_rc1.tar.gz b99973c805f38b549dbeaf88701c0abeff8b0e8eaa4066df47cac10a32097523 boost_1_64_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

9 8

[Trac] Spam and suspicious attachments
by Mateusz Loskot 19 Apr '17

19 Apr '17

Hi, I'm not sure what is the correct admin contact to report spam on Trac, so posting here. Number of suspicious attachments (.exe, .jpg) have been submitted to this ticket during recent period of 3 years https://svn.boost.org/trac/boost/ticket/8070 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[ranges] Please merge the long standing pull request
by Antony Polukhin 18 Apr '17

18 Apr '17

Hello, There's a year old pull request https://github.com/boostorg/range/pull/44 Please merge it to the develop branch. The pull request is a blocker for improving Boost.Algorithm (https://github.com/boostorg/algorithm/pull/35) https://github.com/boostorg/range/pull/44 changes were adopted into C++17 standard library.So the change is not innovative. -- Best regards, Antony Polukhin

2 2

Serialization support for colony container
by Brian Wood 17 Apr '17

17 Apr '17

Shalom It's looking like Matthew Bentley's colony container -- http://plflib.org -- is going to pass over Boost on it's way to the standard. I've added serialization support for this container to the C++ Middleware Writer and added some code that tests that support to my repo -- https://bitbucket.org/webenezer/onwards . I enjoyed Jon Kalb's CppChat show where he talked to Matthew about this container -- http://www.slashslash.info/cppchat/ https://www.youtube.com/watch?v=SFAJ238rBNw -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Guinea pigs for testing GSoC submission ranking
by Niall Douglas 16 Apr '17

16 Apr '17

Google have removed the ability for the community to rank proposals plus they force proposals to be sent to us in the highly unuseful PDF format. I've come up with a stopgap solution, and need guinea pigs for testing it. If you're game, please send me your google login name and I'll send you instructions. My thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

[metal] Formal Review - Request for Endorsement
by Bruno Dutra 16 Apr '17

16 Apr '17

Dear Community, I'd like to formalize what has been known to many for some time now and request the formal review of Metal, a modern C++14 library designed to make template metaprogramming intuitive and effectively replace Boost.MPL. Klemens Morgenstern has kindly offered to manage the review process. The library is available on github at https://github.com/brunocodutra/metal The full documentation is available online at http://brunocodutra.github.io/metal/ Up to date benchmarks are uploaded daily to metaben.ch Great effort has been put into making Metal as portable to different compilers as possible. Currently, the following compilers are tested in continuous integration using Travis and Appveyor: * GCC 4.7 and above * Clang 3.4 and above * Xcode 6.4 and above * Visual Studio 14 (2015) and above * MinGW 5 and above Complying with the new Boost policy, I'd like to kindly request those interested in seeing Metal in boost to take a look at it and endorse this request for formal review. Regards, Bruno

5 6

[config] What to call macros to indicate deprecated/removed components
by John Maddock 16 Apr '17

16 Apr '17

We now have several former C++ features which are removed in C++17: auto_ptr random_shuffle binders unary/binary_function And we're getting requests for configuration macros for these, the question is what to call them? We could stick with the (easy to implement) existing naming and just use: BOOST_NO_<FEATURE> or we could use: BOOST_<STD>_REMOVED_<FEATURE> which is a bit more work as all the scripts that rely on the BOOST_NO/BOOST_HAS convention need updating. Any other suggestions/preferences? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 6

[typeof][scope_exit] VS2017 and option /permissive-
by Daniela Engert 16 Apr '17

16 Apr '17

Hello, late last year, VS2017RC gained a compiler option /permissive- which disables some non-conforming behaviour. Source code that was accepted by previous versions of msvc, and still is accepted by msvc 14.1 without this compiler option, is rejected and flagged as an error if /permissive- is engaged. For more on this see https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/. While checking our company's codebase for possible problems related to that I noticed compile errors in Boost.Log and traced the problem back to Boost.Typeof and in particular "libs\typeof\include\boost\typeof\msvc\typeof_impl.hpp". Therein is code emulating the missing __typeof__ keyword by taking advantage of a silent msvc compiler 'bug' as a 'feature'. Parts of this code are duplicated in a msvc-specific workaround in Boost.Scope_Exit. This compiler bug is no longer silent with /permissive- in place but rather a hard error. As it turns out, I'm not the first to be bitten by this: ticket #12900 tells the same story. Many other Boost libraries use Boost.Typeof directly or indirectly and therefore suffer from the same problem (like Boost.Log in my particular case). I've implemented a possible solution and created two pull-requests: - https://github.com/boostorg/typeof/pull/7 - https://github.com/boostorg/scope_exit/pull/3 The patches only affect msvc 14.1. With these patches applied, the test results of the full Boost testsuite are the same as without these patches. I don't know enough about __typeof__ to decide if my emulation is compatible in every aspect, but at least it's good enough to pass the testsuite. There are two other compile failures introduced with /permissive- in place which are compiler bugs which need to be addressed by Microsoft's compiler team. Fortunately these are very specific to just two libraries, Boost.Spirit.Repository (one test case) and Boost.Geometry (two test cases caused by one single function). -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

2 8

Boost licensing information
by Fabrizio Riente 15 Apr '17

15 Apr '17

Dear Boost Members, I'm Fabrizio Riente and I'm a researcher from the Politecnico di Torino in Italy. I'm using some part of boost libraries in our application. In particular we are using boost spirit, odeint and serialization. In the next future, we would like to release this tool for free for research purposes. I read that at the moment boost is released under Boost license. I was wandering if under this license it is possible to distribute the application for free to other universities and interested people without sharing the source code. Thanks in advance for your time. Best regards. Fabrizio Riente -- Fabrizio Riente, Postdoctoral Research Associate Politecnico di Torino, Dept. of Electronics and Telecommunications C.so Duca degli Abruzzi 24, I-10129, Torino, Italy Phone: +39 011 090 4241, Email: fabrizio.riente(a)polito.it

15 43

Header Inclusion practices
by Robert Ramey 15 Apr '17

15 Apr '17

As long as I can remember, it's been my practice to write program code to minimize dependencies on the environment in which it is built. By environment I mean things external to the code itself like environmental and command line variables, directory context etc. As part of this I use rules for header file inclusion: a) use #include "header.hpp" for files in the same directory as the current source file. b) use #include "other directory/header.hpp" for files which are known to be in a specific place relative to the current file. This shows up in things like: #include "../include/header.hpp" for tests and examples. c) use #include <boost/serialization/xml_archive.hpp> for files which are found by looking in directories listed in "-I" switches and environmental variables (INCLUDE). I generally try not to depend upon any environmental variables as I always forget to set them or even how to set them. Come to think about it. I don't know how my build system finds the boost libraries. I presume it's through some IDE/Bjam/CMake setting which I can never remember. d) use #include <iostream> for standard library components. Presumably these are routed to some directory relative to the compiler. So some of my source files look like: // interval.hpp header for safe numerics library #include <limits> #include <cassert> #include <type_traits> #include <array> #include <initializer_list> #include <boost/logic/tribool.hpp> #include <boost/core/demangle.hpp> #include "utility.hpp" // log #include "checked_result.hpp" #include "checked.hpp" and // example using he safe numerics library #include <iostream> #include <limits> #include <boost/integer.hpp> #include "../include/cpp.hpp" #include "../include/exception.hpp" #include "../include/safe_integer.hpp" #include "../include/safe_range.hpp" This has raised consternation in some quarters - but I don't see anything wrong with it. It basically means that only the <boost libraries are depended on the whole b2 business. I didn't want the incubator version of the the safe numeric library to depend on the library having been accepted into boost have have b2 run. Also I don't like adding the library to boost - and having to change all the headers. What if someone want's to run the tests/examples outside of the boost tree. As far as I know this question has never been asked before and I'm curious to know what others might have to say about this. Robert Ramey

10 21

gil: extension/numeric missing in tarball(s)
by Tim Blechmann 14 Apr '17

14 Apr '17

hi all, the complete folder with the gil numeric extensions is not included in the tarball ... is this a bug or a feature? https://github.com/boostorg/gil/tree/develop/include/boost/gil/extension/nu… thnx, tim

4 6

[release 1.64] - BOOST_NO_CXX17_STD_APPLY missing in documentation
by Oliver Kowalke 14 Apr '17

14 Apr '17

I checkted the documentation of boost-1.64 beta2 and it seams that the documentation lost the description of BOOST_NO_CXX17_STD_APPLY. May I provide a patch that gets merged into the 1.64 release? Oliver

3 3

[config] defect macro for chrono literals
by Oliver Kowalke 14 Apr '17

14 Apr '17

boost.config defines BOOST_NO_CXX11_USER_DEFINED_LITERALS but I believe this defect macro could not be used for detecting chrono literals support. Should the new BOOST_NO_CXX14_CHRONO_LITERALS depend on the compiler or stdlib version? AFAIK chrono literals are available since gcc-4.9.3 (clang?, intel?, msvc?). Oliver

2 2

[CallableTraits] Closing the review period
by Louis Dionne 13 Apr '17

13 Apr '17

Dear Boost, The review period for CallableTraits is about to conclude (in about one hour, PST). So far, I have counted 5 formal reviews, alongside with other valuable feedback. All 5 formal reviews recommend acceptance (along with improvement suggestions, but I read none of them as being conditional). I will weight the different comments received through formal and informal reviews and come back with a decision regarding CallableTrait's inclusion in Boost by the end of next week. Thanks for everyone's involvement in the review. Louis P.S.: If you have a late review, submit it ASAP and I will consider it!

1 0