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