March 2017 - Boost - lists.preview.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

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

[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

[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

[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

[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

[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

[release] 1.64.0 post-beta merges
by Rene Rivera 11 Apr '17

11 Apr '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See < https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> -- The Boost Release Team

13 56

[flat_set] When to sort?
by Vladimir Batov 10 Apr '17

10 Apr '17

I've been using boost::container::flat_set with quite a success until recently when I profiled my app to see that 30-50% of the run-time was spent in insert() for a container of around 50,000 in size. So, I had to replace boost::container::flat_set with a vector variation which inserts as a vector (no sorting). However, when it is the time to call begin(), end(), find(), it sorts once. That shaved the mentioned overhead off. Say, one run is down from 17s to 10s and the likes. I wonder if that should be the boost::container::flat_set default behavior rather than sorting the underlying container with every insert(). After all, as a user I do not care if the underlying container is sorted... until I start using/traversing it, right? Or maybe I am missing something in boost::container::flat_set which already allows me to do something of that sort?

11 37

Announcing CallableTraits' formal review next week (April 3rd)
by Louis Dionne 09 Apr '17

09 Apr '17

Dear Boost community, The formal review of Barrett Adair's CallableTraits library starts Monday, April 3rd and ends on April 12th. CallableTraits is a C++11 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal P0172, and removes the need for template specializations for different function signatures. You can find the documentation of the library here: http://badair.github.io/callable_traits/doc/html/index.html and the GitHub repository here: https://github.com/badair/callable_traits We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Regards, Louis

4 4

[VS2017][release] vswhere.exe
by Mateusz Loskot 06 Apr '17

06 Apr '17

Hi, This is regarding issues with locating VS 2017 toolset(s). >From CMake ml, I learned about vswhere utility being developed by Microsoft https://github.com/Microsoft/vswhere vswhere.exe (390 KB) is downloadable from https://github.com/Microsoft/vswhere/releases I'm not sure how exactly, but perhaps it would solve some of the Boost.Build's headache (eg. particular PowerShell version required). For example, it can find all VS versions I've got installed (10.0, 11.0, 12.0, 14.0, 15.0): vswhere.exe -legacy find a particular version: vswhere -legacy -version [11.0,12.0) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

15 38

[mailing list] No Reply-To in messages?
by Andrey Semashev 05 Apr '17

05 Apr '17

Hi, Sometimes I can see messages from the mailing list that have no Reply-To header. For example, this is the headers from a recent email from the ML: Delivered-To: andrey.semashev(a)gmail.com Received: by 10.223.171.174 with SMTP id s43csp1184445wrc; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) X-Received: by 10.233.239.75 with SMTP id d72mr28079608qkg.313.1490097251746; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Return-Path: <andrey.a.davydov(a)gmail.com> Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com. [2607:f8b0:400d:c09::233]) by mx.google.com with ESMTPS id 5si5329794qty.259.2017.03.21.04.54.11 for <andrey.semashev(a)gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 04:54:11 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) client-ip=2607:f8b0:400d:c09::233; Authentication-Results: mx.google.com; dkim=pass header.i=(a)gmail.com; spf=pass (google.com: domain of andrey.a.davydov(a)gmail.com designates 2607:f8b0:400d:c09::233 as permitted sender) smtp.mailfrom=andrey.a.davydov(a)gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: by mail-qk0-x233.google.com with SMTP id y76so54702989qkb.0 for <andrey.semashev(a)gmail.com>; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=oPSYU2baFZEWMUKF/s2hay278FTdFBfitQp4TNz5piq0zMWNqePuZaXbUD5SPP0Cnp He9gQzhynjuN/Lf4fpUtqjOWyntF2BSSrdpYbCSmaWnnSQjTz5s53EkOSVgojqHCfmVr A3CSJNK5QdAwkNAm+JQRIShSRO/YpWtK90Lhoa9lKlWF+JtIMwCgFG3h5vN1vw+W1xAB pNoHymY5rZ7Uh0WUHMlpEF/tmkD/tZzDss++3j/lKZNgX66VefCpi510BjKKkFfU2xdy zBba1I5hOOohBUzhlkYf5fSxZ1BkC6FSOizONZr1Mlx8AXLhl2MvmfW6KtR9nt9rjmSa Sfhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Az1Qy0ABDDY/isZXuI8r58lTLTG+E/wp0e0IliVZOAk=; b=OAFamTGJr76H6gmaG7LGcCRyHIp+Kj1SEs188yLqxEQGCvhYYdB8wMs6GsOYL0wYSY 9M1gYeXwexivqs+WF5Reg9CCh2mnkCUWTM6nSu9/B05sXFBUL/sVyEr7OuSXJpzVqOxl cZorectxLhbWqIqClTxYjSDNDKPJB9n+3OntHKp5l2gJY3mMPaILXbXRh6XXCMHxpYIy w1um18ndeJ0Ed7/nkhGKlzD2HvyPpkVPhjM+hhWmb+lxnVNhbpBFsoor28Yx5arAnVWb 0JndOFeqB3tfjv9DA5x/kuSStkSuG2Q439Fvd/2UuWKsqaR4JhaBejrE7jEnJgrN69on 8wfQ== X-Gm-Message-State: AFeK/H24Tvn8HI3rOm/9DXmcPc8Hok/lT3XOC2lfnuuWDiN5TsbtV56nLqNTPypggKQsasFDZvOER50I+HaBMH84 X-Received: by 10.55.15.195 with SMTP id 64mr28730703qkp.131.1490097251370; Tue, 21 Mar 2017 04:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.157.129 with HTTP; Tue, 21 Mar 2017 04:54:10 -0700 (PDT) In-Reply-To: <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> References: <CAN1iZb7pGGaFe9OKyDKxMB0Nryiqa3pxk5hLQY+1ybUCMNrZBQ(a)mail.gmail.com> <D5F339D7-3F03-4363-A2A5-F611FE8C76F0(a)gmail.com> <CAN1iZb54emhE_G9McfCmO2nN6D-qWqQSgSC-w1HdRqCAh08c8Q(a)mail.gmail.com> <14065012-bde4-142d-eedf-b5fbf1f51d91(a)gmail.com> From: Andrey Davydov <andrey.a.davydov(a)gmail.com> Date: Tue, 21 Mar 2017 14:54:10 +0300 Message-ID: <CAN1iZb6VHEUJvt9h8JN_1EubOcYponiEjdXWQGcGZ+VjU_hKJA(a)mail.gmail.com> Subject: Re: [boost] [smart_ptr] Is there any interest in unique_ptr with type erased deleter? To: boost(a)lists.boost.org Cc: Andrey Semashev <andrey.semashev(a)gmail.com> Content-Type: multipart/alternative; boundary=001a1146f4805976ff054b3c4d27 As a result, when I press Reply, the reply is addressed to the original email sender instead of the mailing list, which is really easy to miss before sending the message. Is it possible to ensure that every email from the ML contains boost(a)lists.boost.org in its Reply-To header? PS: I'm not a guru in email protocols, so if there is another more appropriate way of doing this then that would be fine with me.

13 35

[gsoc17] My proposal
by GuillermoReyes 01 Apr '17

01 Apr '17

Dear Vissarion and Adam, My name is Guillermo- a Computer science student at UCLA. I am excited at the possibility of contributing to such a useful library! My application is not yet complete, but I will post my draft on here to demonstrate my intent to participate in the program. For the competency test, I began to implement a representation of points on earth and used the great-circle formula to calculate the shortest distance between two points. I will have a more in-depth explanation of the code by the final iteration of the draft along with the complete proposal and application. Sincerely, Guillermo R. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-My-proposal-tp4693288.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[Stacktrace] Review 2 Manager report
by Niall Douglas 31 Mar '17

31 Mar '17

Many thanks to all those who participated in the second review of proposed Boost.Stacktrace. I received the following formal reviews: 1. Peter Dimov (ACCEPT) 2. Vladimir Batov (ACCEPT) 3. Artyom Bellis (CONDITIONAL ACCEPT) 4. Bjorn Reese (ACCEPT) 5. Edward Diener (ACCEPT) Extensive comments without a formal recommendation were also made by: 1. Mark Bartosik 2. Florian Weimer Some of the more important conditions for acceptance as judged by the review manager are: * Problems on FreeBSD (and by inference OS X?). * Per frame execution of addr2line rather than calling it once. * Throw-with-trace was asked for by a lot of people. * One reviewer suggested that the addr2line backend was async signal unsafe. My reading of the code is that it is async signal unsafe to parse a stacktrace (and unavoidably so on any platform), but the capture of backtraces is now fully async signal safe. * Some disliked the bringing in of windows.h and the COM headers on Windows. For a header only library I consider this acceptable, Stacktrace when configured in non-header only mode does not inject windows.h into everything including stacktrace. Congratulations to Antony on getting yet another library of his into Boost! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[Beast] Redesigned HTTP algorithms and parser!
by Vinnie Falco 31 Mar '17

31 Mar '17

Background: Websocket connections start with an HTTP UPGRADE request/response sequence. Often people want to customize this handshake so I added code in Beast to read and write HTTP messages. Upon reviewing the HTTP RFC (rfc2616 and rfc7230) it seemed to be logical that the HTTP message could be modeled as a single class. And there could be free functions implementing the algorithms to serialize and deserialize these messages in th HTTP/1 format. I took this as far as I could and I was pretty happy with the result. You have functions like read, async_read, write, and async_write which take beast::http::message objects as parameters. Example: http://vinniefalco.github.io/beast/beast/ref/http__read/overload3.html The innovation here is the "Body" template type which controls not only the type of container used to represent the body but also the algorithms used to transfer bytes from the message body on the wire into and out of that container. The Body concept, and its nested Reader and Writer concepts, are documented here: http://vinniefalco.github.io/beast/beast/ref/Body.html http://vinniefalco.github.io/beast/beast/ref/Reader.html http://vinniefalco.github.io/beast/beast/ref/Writer.html Previous efforts and HTTP implementations focused heavily on the representation and parsing of the headers. To my knowledge Beast is the first implementation to provide caller flexibility in the body representation. Now the Beast websocket implementation has a reasonable set of primitives it could use to perform the handshake, and users could get control of that process. The Problem: Unfortunately, while treating the message as an object that can be read/written atomically works great for example programs and trivial use-cases, it fails in the real world. These are issues with it: * The caller must commit to a Body representation before receiving the HTTP Header * No way to properly read and respond to Expect: 100-continue * An efficient HTTP relay function (one that does not buffer the entire body up front) cannot be implemented by the caller * The caller cannot reasonably set a timeout, for example what if the body is 2 gigabytes received over a slow connection? * The parser interface forces algorithms to perform an unnecessary buffer copy for body containers that are entirely stored in memory (e.g std::string or boost::asio::streambuf). These issues sparked quite a bit of discussion on GitHub: https://github.com/vinniefalco/Beast/issues/154 https://github.com/vinniefalco/Beast/issues/265 In October of 2016 these problems became apparent. I tried a lot of different ideas to improve the design to solve it, but none of them worked. Some of my co-workers looked at it but we didn't really find anything great. One user in particular, on GitHub, had strong ideas involving the concept of "completion conditions" to augment the read/parse algorithms but it didn't feel right to me. The Solution: After suffering from writer's block for 5 months inspiration hit and I tried a combination of interface changes that got the design to where it needs to be to solve these problems. * The Reader concept is refined into two types: "indirect" readers, and "direct" readers. This is described here: http://vinniefalco.github.io/stage/beast/beast/ref/Reader.html * The parser exposes a small number of internal states, informing callers of where it is at and giving the caller control over if and when the parser advances to the next state: https://github.com/vinniefalco/Beast/blob/http/include/beast/http/basic_par… * The parser is rewritten to work only on linear buffers (allowing it to be optimized to become 20 times faster if SSE2 instructions are allowed). To facilitate this requirement, the flat_streambuf class is provided which works just like a basic_streambuf except it guarantees a single buffer. If the parser is given multiple buffers, it allocates memory to flatten it: https://github.com/vinniefalco/Beast/blob/http/include/beast/core/flat_stre… * New functions parse_some and async_parse_some allow the caller to perform incremental parsing. This allows for the implementation of relay functions, or reading just the header (for Expect: 100-continue): https://github.com/vinniefalco/Beast/blob/http/include/beast/http/parse.hpp… With these changes callers can get control of the inner loop that reads the body off the socket or stream, so they can do whatever custom steps are necessary if they want. They can set timeouts, and write their own loop that calls parse_some repeatedly. I think it solves all of these issues. I've written some test code which demonstrates how direct and indirect body readers are implemented, and what calling code looks like. I've also written a prototype "relay" function (read a message from one socket and efficiently write it to another socket). And there's an example of how Expect: 100-continue might be implemented. These prototypes are located here: https://github.com/vinniefalco/Beast/blob/http/test/http/design.cpp#L30 How to Help? These are some controversial changes and I think they could use some polish and vetting before I merge it to the master branch. Maybe there is something I haven't thought of, or a use-case it doesn't address. Perhaps there is a better way, or perhaps there are tweaks to make it even more usable and understandable. If some kind soul(s) would look through it and offer some feedback, positive or negative, that would be enormously helpful. The formal review for Beast is now scheduled for the first week of July and like an expectant father I am anxious and would like everything to go just right! My only objective is to polish up the library and its documentation so it is in the best possible shape for review. Thanks for listening!

1 1

[release] Boost 1.64.0 Beta 2
by Rene Rivera 31 Mar '17

31 Mar '17

Boost release 1.64.0 beta 2 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/source/> The SHA256 checksums are as follows: 49c9339b9d8e7b2610ef84c80cd10b2252c119ebcc3222450beb0e94c1da1522 boost_1_64_0_b2.7z 92ec7cbf1e77c5979e381dd8104f9e96c0471c276e566272751a981d806db94b boost_1_64_0_b2.tar.bz2 da5670892b7b572808491b13a7b9421c3c18e6f395d6a5ec822466db466eda01 boost_1_64_0_b2.tar.gz 61d6e29e8a1d7503fe13a9d916842f0ec2e625f733b98b29ce563f8cbdb482bf boost_1_64_0_b2.zip The notable difference from Beta 1 is the inclusion of the missing Boost Process library. For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.2/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- 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

6 5

[gsoc17]Proposal draft shared of Boost.Geometry Project 1
by Ruoyun Jing 30 Mar '17

30 Mar '17

Hi Adam, Vissarion, boost all: I have finished my proposal of Boost.Geometry Project 1, I am very pleasure you to give me more advice of my proposal! :) Any aspect of the proposal is OK! I would like to get feed back from you! Looking forward from you! :) Thanks all and Best Regards. Google docs: https://docs.google.com/document/d/1wj9xPSmdehh9MzE-3MGHMu7cwMhDPASUEvU9pJb… Ruoyun Jing -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

1 0

Boost.SIMD review
by serge guelton 30 Mar '17

30 Mar '17

Hi Boost Dev, I'm the core maintainer of Pythran[0], a python-to-native-code compiler focused on numeric computations. For more than 3 years, we've been using Boost.SIMD [1] as a generic backend for SIMD code generation, without much worries. Basically our compiler generates C++ code that includes Boost.simd calls. The big plus to us are: + Performances. The generated code runs at the same speed as the one written with intrinsics; + Target abstraction, esp. concerning the vector size and the various arithmetic operations; + Complete libm API, vectorized, which is a big plus when porting existing code (or when matching an existing API as we do); + Header only, which actually makes it easier for us to ship; + Low requirements (it does not require us to ship a large part of boost).? The compilation time is sometimes a worry, but it has decreased over the year. We don't use complex data movement like shuffle or pack, so I don't have any feedback on that. All in one, if that ever matters, I would be happy to have it integrated in Boost! ++ Serge [0] https://pythonhosted.org/pythran/ [1] https://github.com/NumScale/boost.simd

1 0

NuDB: A fast key/value insert-only database for SSD drives in C++11
by Vinnie Falco 30 Mar '17

30 Mar '17

I just released version 1.0.0 of my header-only C++11 library NuDB. Its quite a mature library, haven't had to make any changes in a while. Its been running on production servers for 2 years or so with no problems, managing ever-growing databases of 2TB. I'm wondering what the level of interest, if any, there would be for making this a part of Boost. You can check it out here: https://github.com/vinniefalco/NuDB

11 91

Problem creating mapping from string to vector_expression
by SHIVAM MITTAL 30 Mar '17

30 Mar '17

Hi, I have been trying to create a mapping from string to ublas::vector_expression. template <class T> boost::unordered_map<std::string, vector_expression <T> > c; vector<int> v (10); for (unsigned i = 0; i < v.size (); ++ i) v (i) = i; c <int>["first"] = v; I have been getting this error : error: no match for ‘operator=’ (operand types are ‘boost::unordered::unordered_map<std::__cxx11::basic_string<char>, boost::numeric::ublas::vector_expression<int>, boost::hash<std::__cxx11::basic_string<char> >, std::equal_to<std::__cxx11::basic_string<char> >, std::allocator<std::pair<const std::__cxx11::basic_string<char>, boost::numeric::ublas::vector_expression<int> > > >::mapped_type {aka boost::numeric::ublas::vector_expression<int>}’ and ‘boost::numeric::ublas::vector<int>’) columns <int>["first"] = v; Please help.

1 0

[build][geometry][regression] Geometry develop regression tests are blank
by Adam Wulkiewicz 29 Mar '17

29 Mar '17

Hi, Boost.Geometry develop tests (http://www.boost.org/development/tests/develop/developer/geometry.html) stopped showing around 22.03. The first blank run (teeks99-03-dc3.9-1z-Docker-64on64) is from Wed, 22 Mar 2017 01:20:13. Do you have an idea what may be the cause? I see that many changes in Build and Regression was done around 22.03. Geometry was also modified that day but the first commit is from 12:40+1 so later than the first blank run. I checked the XML of one of them (teeks99-09-n-win2012R2-64on64) and it seems that the revision attribute of <test-log> tag is not set for the most of the tests. I'm currently running the regression.py myself in hope of finding the cause. I see that in bjam.log the only tests that are dumped are: boost-test(RUN_PYD) "geometry/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN_PYD) "geometry/extensions/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN) "geometry/index/varray_old" : "libs/geometry/index/test/varray_old.cpp" boost-test(RUN) "geometry/index/varray" : "libs/geometry/index/test/varray.cpp" boost-test(RUN_PYD) "geometry/index/__boost_check_library__" : "status/boost_check_library.py" varray tests are the only ones that are run at the most top level of Geometry Jamfiles (of sublib geometry/index in this case) with test-suite: https://github.com/boostorg/geometry/blob/develop/index/test/Jamfile.v2#L24 The rest of the tests is run with build-project, also for the main part of the library: https://github.com/boostorg/geometry/blob/develop/test/Jamfile.v2#L26 The varray tests results are shown on the regression page and can be found in bjam.log and in XML file with revision set. The rest of the tests is neither dumped nor has the revision set, however they are run during regression testing so can be found in bjam.log and also in XML file but with empty revision. Adam

2 5

Broken link to conversion library
by Antony Polukhin 29 Mar '17

29 Mar '17

Hello, There is a broken link to Conversion library on the changelog page: http://www.boost.org/users/history/version_1_64_0.html Can not figure out what's the problem. Could someone take a look? -- Best regards, Antony Polukhin

3 3

[Boost.Test] Custom DataSet compiler error with no match for »operator^
by Olaf Peter 29 Mar '17

29 Mar '17

Hello, I run into a compile problem with [Boost.Test] DataSet. I can reduce it by re-using the example provided by the docs: http://www.boost.org/doc/libs/1_62_0/libs/test/doc/html/boost_test/tests_or… #define BOOST_TEST_MODULE dataset_example68 #include <boost/test/included/unit_test.hpp> #include <boost/test/data/test_case.hpp> #include <boost/test/data/monomorphic.hpp> #include <sstream> namespace bdata = boost::unit_test::data; // Dataset generating a Fibonacci sequence class fibonacci_dataset { public: // Samples type is int using sample=int; enum { arity = 1 }; struct iterator { iterator() : a(1), b(1) {} int operator*() const { return b; } void operator++() { a = a + b; std::swap(a, b); } private: int a; int b; // b is the output }; fibonacci_dataset() {} // size is infinite bdata::size_t size() const { return bdata::BOOST_TEST_DS_INFINITE_SIZE; } // iterator iterator begin() const { return iterator(); } }; namespace boost { namespace unit_test { namespace data { namespace monomorphic { // registering fibonacci_dataset as a proper dataset template <> struct is_dataset<fibonacci_dataset> : boost::mpl::true_ {}; }}}} // Creating a test-driven dataset BOOST_DATA_TEST_CASE( test1, fibonacci_dataset() ^ fibonacci_dataset(), fib_sample, exp) { BOOST_TEST(fib_sample == exp); } error: no match for 'operator^' (operand types are 'boost::unit_test::data::result_of::make<fibonacci_dataset>::type {aka fibonacci_dataset}' and 'fibonacci_dataset') fibonacci_dataset() ^ fibonacci_dataset(), My use case has to load input and expect files provides by two datasets. How to fix it? Thanks, Olaf

3 3

Re: [boost] [Boost-users] Going insane trying to build boost for android
by Robert Dailey 29 Mar '17

29 Mar '17

On Mon, Mar 27, 2017 at 11:54 AM, John Maddock <jz.maddock(a)googlemail.com> wrote: > >> That won't do me any good because I'm already using this toolchain >> perfectly fine via CMake and ndk-build. bjam isn't working, maybe >> because I haven't set up the config.jam file properly. I'm not sure at >> this point. Boost is the only thing not working here. > > > Then if you compare the compilation command line generated when building > under b2 and when building under cmake the error should be obvious? I took your advice and compared a real build that worked using CMake (using a simple test cpp file) and what I got from b2. Here is the command line used to build the sample app using CMake. Note that the compilation succeeded: C:\android\ndk\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-g++.exe --sysroot=C:/android/ndk/platforms/android-15/arch-arm -Dndk_test_EXPORTS -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -march=armv7-a -mthumb -mfpu=vfpv3-d16 -mfloat-abi=softfp -funwind-tables -no-canonical-prefixes -fexceptions -frtti -g -fPIC -std=gnu++14 -MD -MT CMakeFiles/ndk_test.dir/main.cpp.o -MF CMakeFiles\ndk_test.dir\main.cpp.o.d -o CMakeFiles/ndk_test.dir/main.cpp.o -c ../main.cpp And here is the command line from b2: "C:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++" -c -x c++ -O3 -Wno-inline -Wall --sysroot=C:/android/ndk/platforms/android-15/arch-arm -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -std=c++14 -fno-strict-aliasing -D__GLIBC__ -DANDROID -D__ANDROID__ -D_GLIBCXX__PTHREADS -D__arm__ -D_REENTRANT -O2 -DNDEBUG -H -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_SOURCE -DBOOST_ATOMIC_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o" "libs\atomic\src\lockpool.cpp" The build for boost still fails. Note I also passed the -H option, so I could see the include searches performed by clang as it was building boost. The output is long, but I've included it below. Can anyone help me identify why boost still won't build? clang-linux.compile.c++.without-pth bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o "C:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++" -c -x c++ -O3 -Wno-inline -Wall --sysroot=C:/android/ndk/platforms/android-15/arch-arm -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++/include -isystem C:/android/ndk/sources/android/support/include -isystem C:/android/ndk/sources/cxx-stl/llvm-libc++abi/include -isystem C:/android/ndk/platforms/android-15/arch-arm/usr/include -std=c++14 -fno-strict-aliasing -D__GLIBC__ -DANDROID -D__ANDROID__ -D_GLIBCXX__PTHREADS -D__arm__ -D_REENTRANT -O2 -DNDEBUG -H -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_SOURCE -DBOOST_ATOMIC_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2\libs\atomic\build\clang-linux-android\release\link-static\target-os-android\threadapi-pthread\threading-multi\lockpool.o" "libs\atomic\src\lockpool.cpp" . C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\cstddef .. C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\__config .. C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ... C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include/__stddef_max_align_t.h .. C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\__nullptr . .\\boost/config.hpp .. .\\boost/config/user.hpp .. .\\boost/config/select_compiler_config.hpp .. .\\boost/config/compiler/clang.hpp .. .\\boost/config/select_stdlib_config.hpp .. .\\boost/config/stdlib/libcpp.hpp .. .\\boost/config/select_platform_config.hpp .. .\\boost/config/platform/linux.hpp ... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\cstdlib .... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stdlib.h ..... C:/android/ndk/sources/android/support/include\\stdlib.h ...... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\stdlib.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/cdefs.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/cdefs_elf.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\android/api-level.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........ C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........ C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ....... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\string.h ........ C:/android/ndk/sources/android/support/include\\string.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\string.h .......... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\malloc.h ........... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\alloca.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\strings.h ........ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/types.h ......... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h .......... C:\\android\\ndk\\toolchains\\llvm\\prebuilt\\windows-x86_64\\bin\\..\\lib64\\clang\\3.8.275480\\include\\stddef.h ......... C:/android/ndk/sources/android/support/include\\stdint.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\stdint.h ........... C:/android/ndk/sources/cxx-stl/llvm-libc++/include\\stddef.h ........... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/_types.h ............ C:/android/ndk/platforms/android-15/arch-arm/usr/include\\machine/_types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/posix_types.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/stddef.h ........... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/compiler.h .......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\asm/posix_types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\asm/types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\linux/types.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\machine/kernel.h ......... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\sys/sysmacros.h ....... C:/android/ndk/platforms/android-15/arch-arm/usr/include\\memory.h In file included from libs\atomic\src\lockpool.cpp:16: In file included from .\boost/config.hpp:57: In file included from .\boost/config/platform/linux.hpp:15: C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:108:9: error: no member named 'strtold' in the global namespace using ::strtold; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:126:9: error: no member named '_Exit' in the global namespace using ::_Exit; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:149:9: error: no member named 'at_quick_exit' in the global namespace using ::at_quick_exit; ~~^ C:/android/ndk/sources/cxx-stl/llvm-libc++/include\cstdlib:150:9: error: no member named 'quick_exit' in the global namespace using ::quick_exit; ~~^

2 1

[review queue] What to do about the library review queue?
by Niall Douglas 28 Mar '17

28 Mar '17

Dear Boost, I see that new candidate Boost libraries entering the review queue have exploded in recent years, with no less than *twenty-three* proposed libraries awaiting a review. As the ongoing strength and vitality of Boost is inextricably linked to new growth, I think that waiting around for years for someone to volunteer to manage a review is not healthy. If a library author has invested the very significant effort to develop a Boost-quality library, the least Boost can do is to try harder to provide timely reviews and that means persuading more people to volunteer to manage reviews. In the past people have argued that for every library you submit for review, you should manage a review in return. Myself, Antony and a few others have adhered to that rule, and if every library author did so there would be no outstanding review queue. However there are problems in that in itself in terms of moral hazard, and also because the review manager needs to usually be fairly expert in a library being reviewed, else it can be very hard to judge the worth and validity of reviews. A shortage of suitably expert review managers will always be a problem for some types of library. I therefore ask boost-dev what to do? Some options: 1. Pay US$1000 (one thousand) dollars to each person who manages a review. In case you're worried Boost doesn't have the money, it does in spades, that's not a problem. For $23,000 we could clear the current review queue assuming none of the problems mentioned yet. 2. Pay US$1000 dollars to the manager and 2x $500 dollar payments to those writing the top two most useful reviews as judged by the review manager. That makes the cost $2000 per library accepted or rejected, or $46,000 to clear the current review queue. 3. In my own opinion from reviewing the review queue, a good 25% of the libraries in the queue are not ready for review due to obvious glaring deficiencies in the documentation or code. Spending a grand on those libraries which will very obviously be rejected isn't worth the money. What should we do about those? One approach could simply be to trust review managers to not abuse the thousand dollar fee. Another could be that before each new review, the prospective manager needs to write a single line comment on why they did not choose the other libraries in the queue and publish that here before starting a review. That would quickly identify those libraries in the queue which a majority of managers think have serious problems and could never pass any review. If say a library in a queue accumulates three single line black marks, the author might be encouraged to withdraw it. 4. Finally there is the problem of libraries of high quality, but not a good fit for Boost because they are so esoteric and niche that nobody could provide a useful review, and without useful reviews the review manager can't really recommend acceptance. This will be an increasing problem with time anyway as more of the low hanging C++ library fruit is picked, but I suppose one could just kick that decision can down the road and see if 2x $500 payments might help scare up more high quality reviews. 5. We could try guilting more people into review managing, and redouble banging the drum to scare up more volunteers. I look forward to seeing what people think. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

29 104

[1.64] Can't configure msvc-14.1
by John Maddock 28 Mar '17

28 Mar '17

So... I have in my user-config.jam: using msvc : 14.1 : "M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/cl.exe" ; And this did work at one point, but both with latest develop and master I now get: M:/data/boost/boost/tools/build/src/tools\msvc.jam:1103: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup ? : default-global-setup-options : default-setup ) * called with: ( 14.10.25017 14.10.25017 : M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64 : M:\Compilers\VC2017\VC\Tools\MSVC\14.10.25017\bin\HostX64 : <command>M:\Compilers\VC2017\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe <command>M:/Compilers/VC2017/VC/Tools/MSVC/14.10.25017/bin/HostX64/x64/cl.exe : i386 : : x86 : vcvars32.bat ) * extra argument 14.10.25017 M:/data/boost/boost/tools/build/src/tools\msvc.jam:811:see definition of rule 'generate-setup-cmd' being called M:/data/boost/boost/tools/build/src/tools\msvc.jam:201: in configure M:/data/boost/boost/tools/build/src/tools\msvc.jam:153: in msvc.init M:/data/boost/boost/tools/build/src/build\toolset.jam:43: in toolset.using M:/data/boost/boost/tools/build/src/build\project.jam:1052: in using C:\cygwin64\home\John\user-config.jam:46: in modules.load M:/data/boost/boost/tools/build/src\build-system.jam:249: in load-config M:/data/boost/boost/tools/build/src\build-system.jam:389: in load-configuration-files M:/data/boost/boost/tools/build/src\build-system.jam:524: in load M:\data\boost\boost\tools\build\src/kernel\modules.jam:295: in import M:\data\boost\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build M:\data\boost\boost\boost-build.jam:17: in module scope Anyone any ideas? Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

1 0

Clang 4.0.0 MPL error in Boost next.hpp and prior.hpp
by Paul A. Bristow 28 Mar '17

28 Mar '17

I am trying to check code that works on VS2015 update 3 and GCC 6.3.0 using Clang 4.0.0 I am using the CodeBlocks IDE (though I don't think that is relevant). The code indirectly uses next.hpp and prior.hpp There are several warnings like this (after adding the -Wignored-attributes option) C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\immintrin.h|45|warning: __declspec attribute 'intrin_type' is not supported [-Wignored-attributes] I:\modular-boost\boost\mpl\next_prior.hpp|44|error: too many arguments provided to function-like macro invocation| Following suggestions in this thread, I have added -Wno-invalid-token-paste http://clang-developers.42468.n3.nabble.com/invalid-token-paste-td4025526.h… and also -DBOOST_PP_CONFIG_FLAGS=1, but I get a blizzard of errors - see below It would seem that this may be because of a misconfiguration in Boost mpl? If I understand right, the thread above suggests that this is MS pre-processor-specific MPL code because of code in boost/preprocessor/config/config.hpp that determines the MPL code? Is this correct? Target: x86_64-pc-windows-msvc -triple x86_64-pc-windows-msvc19.0.24123 Complete log attached in case this helps. Can anyone say what I am doing wrong and/or suggest a workaround for this? Thanks Paul Compile line is clang++.exe -Wall -fexceptions -Wignored_attributes -D"BOOST_PP_CONFIG_FLAGS()"=1 -m64 -v -Wignored-attributes -Wno-invalid-token-paste -II:\modular-boost -I"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" -c J:\Cpp\Misc\lambert_w_single\lambert_w_single.cpp -o .objs\Misc\lambert_w_single\lambert_w_single.o clang version 4.0.0 (tags/RELEASE_400/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\LLVM\bin "C:\\LLVM\\bin\\clang++.exe" -cc1 -triple x86_64-pc-windows-msvc19.0.24123 In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:23: error: too many arguments provided to function-like macro invocation BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/preprocessor/facilities/expand.hpp:26:10: note: macro 'BOOST_PP_EXPAND_I' defined here # define BOOST_PP_EXPAND_I(x) x ^ In file included from I:\modular-boost\boost/mpl/next.hpp:17: I:\modular-boost\boost/mpl/next_prior.hpp:44:1: error: expected a qualified name after 'typename' BOOST_MPL_AUX_NA_SPEC(1, next) ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:64:11: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_PARAMS(i, typename T) \ ^ I:\modular-boost\boost/mpl/aux_/preprocessor/params.hpp:58:11: note: expanded from macro 'BOOST_MPL_PP_PARAMS' , BOOST_MPL_PP_AUX_PARAM_FUNC \ ^ ... I:\modular-boost\boost/mpl/void.hpp:71:1: error: expected ',' or '>' in template-parameter-list I:\modular-boost\boost/mpl/aux_/na_spec.hpp:161:40: note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC' #define BOOST_MPL_AUX_NA_SPEC(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:154:47: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_NO_ETI' #define BOOST_MPL_AUX_NA_SPEC_NO_ETI(i, name) \ ^ I:\modular-boost\boost/mpl/aux_/na_spec.hpp:65:9: note: expanded from macro '\ BOOST_MPL_AUX_NA_SPEC_MAIN' BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(i, typename T, na) \ ^ note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:38:37: note: expanded from macro 'BOOST_PP_REPEAT_1' # define BOOST_PP_REPEAT_1(c, m, d) BOOST_PP_REPEAT_1_I(c, m, d) ^ I:\modular-boost\boost/preprocessor/repetition/repeat.hpp:43:39: note: expanded from macro 'BOOST_PP_REPEAT_1_I' # define BOOST_PP_REPEAT_1_I(c, m, d) BOOST_PP_REPEAT_1_ ## c(m, d) ^ <scratch space>:64:1: note: expanded from here BOOST_PP_REPEAT_1_BOOST_PP_REM ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

4 53

Constructing string_ref from rvalue string
by Simon Sasburg 28 Mar '17

28 Mar '17

I've just tested our codebase with the 1.64.0 master snapshot, and i've encountered an issue which i've tracked down to this commit: https://github.com/boostorg/utility/commit/9960d9f395b79ee860e39064cd4696 1f76d2cb55 Basically this removes the constructor which allows constructing a boost::string_ref from an rvalue std::string. I am wondering if this is really that dangerous. In our codebase we almost exlusively use boost::string_ref as function parameters, with the understanding that passed string_refs parameters are only valid within the function body. (so you need to copy it into an std::string if you need to access it afterwards) With these constraints i think it is OK to construct a string_ref from an rvalue std::string because the temporary should live long enough. (but please correct me if i'm wrong here) Is the safety (?) added by this commit worth it if it breaks working code? Simon

11 20

Undefined refs when compiling trivial example
by Florian Lindner 28 Mar '17

28 Mar '17

Hello, I took the trivial example from http://www.boost.org/doc/libs/1_63_0/libs/log/example/doc/tutorial_trivial.… and try to compile it. boost 1.63 is compiled by myself without any special options, besides --prefix. % echo $LD_LIBRARY_PATH /home/lindnefn/software/boost/lib: % echo $LIBRARY_PATH /home/lindnefn/software/boost/lib: % echo $CPLUS_INCLUDE_PATH /home/lindnefn/software/boost/include: the LIBRARY_PATH contains all the *.so and *.a files, the INCLUDE_PATH/boost all the headers. but compiling fails: lindnefn@helium ~ % g++ -std=c++11 -DBOOST_ALL_DYN_LINK -pthread -lboost_log_setup -lboost_log -lboost_thread -lboost_filesystem boostlog_trivial.cpp /tmp/ccUc6CtH.o: In function `main': boostlog_trivial.cpp:(.text+0x48): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x76): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0xe8): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x116): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' boostlog_trivial.cpp:(.text+0x188): undefined reference to `boost::log::v2_mt_posix::trivial::logger::get()' /tmp/ccUc6CtH.o:boostlog_trivial.cpp:(.text+0x1b6): more undefined references to `boost::log::v2_mt_posix::trivial::logger::get()' follow /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::record::reset()': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix6record5resetEv[_ZN5boost3log11v2_mt_posix6record5resetEv]+0x23): undefined reference to `boost::log::v2_mt_posix::record_view::public_data::destroy(boost::log::v2_mt_posix::record_view::public_data const*)' /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::record boost::log::v2_mt_posix::sources::basic_composite_logger<char, boost::log::v2_mt_posix::sources::severity_logger_mt<boost::log::v2_mt_posix::trivial::severity_level>, boost::log::v2_mt_posix::sources::multi_thread_model<boost::log::v2_mt_posix::aux::light_rw_mutex>, boost::log::v2_mt_posix::sources::features<boost::log::v2_mt_posix::sources::severity<boost::log::v2_mt_posix::trivial::severity_level> > >::open_record<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::severity, boost::log::v2_mt_posix::trivial::severity_level const> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::severity, boost::log::v2_mt_posix::trivial::severity_level const> const&)': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix7sources22basic_composite_loggerIcNS2_18severity_logger_mtINS1_7trivial14severity_levelEEENS2_18multi_thread_modelINS1_3aux14light_rw_mutexEEENS2_8featuresIJNS2_8severityIS6_EEEEEE11open_recordINS_9parameter3aux15tagged_argumentINS1_8keywords3tag8severityEKS6_EEEENS1_6recordERKT_[_ZN5boost3log11v2_mt_posix7sources22basic_composite_loggerIcNS2_18severity_logger_mtINS1_7trivial14severity_levelEEENS2_18multi_thread_modelINS1_3aux14light_rw_mutexEEENS2_8featuresIJNS2_8severityIS6_EEEEEE11open_recordINS_9parameter3aux15tagged_argumentINS1_8keywords3tag8severityEKS6_EEEENS1_6recordERKT_]+0x3c): undefined reference to `boost::log::v2_mt_posix::core::get_logging_enabled() const' /tmp/ccUc6CtH.o: In function `boost::log::v2_mt_posix::aux::record_pump<boost::log::v2_mt_posix::sources::severity_logger_mt<boost::log::v2_mt_posix::trivial::severity_level> >::~record_pump()': boostlog_trivial.cpp:(.text._ZN5boost3log11v2_mt_posix3aux11record_pumpINS1_7sources18severity_logger_mtINS1_7trivial14severity_levelEEEED2Ev[_ZN5boost3log11v2_mt_posix3aux11record_pumpINS1_7sources18severity_logger_mtINS1_7trivial14severity_levelEEEED5Ev]+0x4b): undefined reference to `boost::log::v2_mt_posix::aux::unhandled_exception_count()' [...] I also tried to omit -DBOOST_ALL_DYN_LINK, add -static instead or use clang++ instead of g++. I also tried to shuffle the order of -l ... All gives the same error. Build machine is a Ubuntu 16.04.4 , g++ 5.4.0. What could be wrong? Thanks, Florian

2 1

Re: [boost] [gsoc17]The implement of Programming competency test From Ruoyun Jing
by Ruoyun Jing 28 Mar '17

28 Mar '17

Hi Adam and Vissarion, During these days I discussed the ideas of project 1 and begin to write my proposal. Here are what I learn about these project. 1.For the approach of compute the 3D cartesian distances first and if these numbers are not "far enough" then fall back to expensive geographic distance calculation otherwise return the result by comparing those numbers obtained by less expensive cartesian compuation. The main problems is declare the "far enough". To figure out this problem, I would implement the method, test the result between function compare_distance and this method, then adjust parameter to limit deviation in an acceptable range(maybe it would be 1e-6 correapongs, the accurate value should be discussed by specific condition) 2.For the approach of perform a local spheroid approximation and return the 2D distance. The main problem is to test the acceptable range of using spheroid approximation. The solution is same as answer above. 3.For the approach of getting 2 intersections of plane (which would be ellipse) with the help given points and compute the respective distances using those ellipses. In my understand of these approach, it means we need to get cross-section through the center of ellipsoid and the geodesic segments. But I am not sure that the geodesic segments of two points whether can get a cross-section through the center of ellipsoid, and whether the cross-section is ellipse that we can calculate the sectorial area easy to compare. After check out the geodesic knowledge from differential geometry for a long time. I got some prove, but I think it isn't very reliable. 4.I have an reliable approach is that we could use the algorithms in "map projection" just like Lambert Conformal Conic, Gauss–Krüger projection, Mercator projection...etc, Those projections make the point on 3D to 2D with reliable functions, although most of these projections use longitude and latitude, we could transform our cartisian coordinate into Spherical coordinate then transform them into longitude and latitude then use the projection to approximately calculate. All of above is what I discussed during these days, Could you please provide me some advise about them so I can strenthen my proposal?And if there has any problems about my poor English description please tell me, I will try my best to explain more clearly:) Thanks all for your reading! Looking forward from you.:) Ruoyun -- Northwest University of China Software Engineering jingry0321(a)gmail.com <jingry0321(a)163.com>

2 3

My Proposal for GSoC
by Mukund Chandra 28 Mar '17

28 Mar '17

Dear Sir, I want you to review the draft of my proposal and suggest me what I should do so that I can work with this project. The project is Project 1 for Boost.Geometry about filtering of compare distance predicates. Here is the link for my Proposal Draft : https://github.com/MukundChandra/Programs-For-GSoC/blob/MukundChandra-patch…

2 1

[gsoc2017] Applying for Boost.Geometry Project 1
by NowhereMan 28 Mar '17

28 Mar '17

Hello, I wish to pursue a path in GSOC 2017 with boost, specifically Project 1 which involves optimization of compare distance predicates. My name is Cody Glassman, a first-year student at my local Community College in Southern California, on a path to obtaining my BS in Computer Science from the University of California system. I am currently working hard developing a concise, yet thorough competency test and am hoping to establish contact with a mentor. Thank you! Cody -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc2017-Applying-for-Boost-Geometry-Pro… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

small_vector alignment
by Tobias Loew 28 Mar '17

28 Mar '17

Hi, I wanted to use a boost::container::small_vector for 64-bit aligned doubles (to be used with SSE): But it seems that the "small-buffer" has a fixed calculated alignment which only depends on the value-type and does not consider the alignment of the (dynamic) allocator. Is this intended or is it a bug in the implementation? best regards Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/small-vector-alignment-tp4692694.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[geometry] Documentation garbage (Re: [Boost-announce] [release] Boost 1.64.0 Beta 1)
by Mateusz Loskot 28 Mar '17

28 Mar '17

On 23 March 2017 at 15:11, Rene Rivera <boost(a)lists.boost.org> wrote: > Boost release 1.64.0 beta 1 is now available at: > [...] > Please download the beta, give it a try, and report any problems you > encounter. I noticed, the package consists of intermediate files from docs generation process of Boost.Geometry: /libs/geometry/doc/doxy/doxygen_output/html_by_doxygen /libs/geometry/doc/doxy/doxygen_output/xml May I ask how documentation of individual library makes it into the package? /libs/geometry/doc/Jamfile.v2 calls our custom make_qbk.py script which is known to not to do any post-generation clean-ups of intermediate files. Shall we add such cleanup to make_qbk.py or it is not relevant for release process? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[gsoc17]Dynamic Shortest Path Computation
by A.I 28 Mar '17

28 Mar '17

Hi, everyone, I am Donghyuk Kim, a Ph.D. Student at KAIST(Korea Advanced Institute of Science and Technology) in South Korea. I've been studying motion/path planning algorithm and I'd like to contribute to a specific algorithm, "Dynamic Shortest Path Computation" in Boost graph library as a google summer code project. It is a tree-based data structure for maintaining single-source to all destination shortest path. It is also known that it outperforms the recomputation of Dijkstra or A* where insertion and deletion of vertex/edge can frequently happen. Here you can check my brief CV including educational/programming background and my interests. https://www.linkedin.com/in/donghyuk-kim-54223355/ Most of my source codes (research/project-purpose things) are in a private repository by our policy, for this reason, the only thing I can share is the below one: https://github.com/aidyk/SGMP The concept of "Dynamic Shortest Path Computation" was originally introduced in [Fully Dynamic Algorithms for Maintaining Shortest Paths Trees] by D. Frigioni, et al. (http://dl.acm.org/citation.cfm?id=338900) I've already implemented a prototype for my research, but testing, coding style unification and much more c++ style modification are required for general purpose. I hope someone find it interesting and be a mentor in this journey. Thanks in advance! Best Regards, Donghyuk Kim a.i(a)acm.org -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc17-Dynamic-Shortest-Path-Computation… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

GSOC Project
by Umar Ali 28 Mar '17

28 Mar '17

I am a Computer Science student trying to apply with MariaDB in GSOC. I have a basic knowledge of SQL and a deeper understanding of C++, and was wondering whether I would have to come up with a project idea inorder to file a proposal or can i submit a proposal inorder to learn without any deeper understanding of programming languages

3 2

[review queue] Beast Review Date - Request
by Michael Caisse 28 Mar '17

28 Mar '17

Hello Wizards! We would like to schedule the Beast review (already in the queue) for the week of July 1 - July 8. Thanks! michhael -- Michael Caisse Ciere Consulting ciere.com

2 1

[release] Boost 1.64.0 Beta 1
by Rene Rivera 27 Mar '17

27 Mar '17

Boost release 1.64.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/source/> The SHA256 checksums are as follows: 8f0ba6b73fad15115049f9b3e7e27eae43be10a94b51a57142f3a27e55ef4beb boost_1_64_0_b1.7z b5c5abf127a3f723dafcc7cf55876c1bda9f014fb1b117f6a7f769e3cc407c4f boost_1_64_0_b1.tar.bz2 a7fe98a9a9f615f6fa68d8ea09ce725d19e3a4fe4719c21c9db29dff88b3b6e3 boost_1_64_0_b1.tar.gz 593005661af8dfe132b2b16bc2cd41339e6acd58456913f353d765090d7868f7 boost_1_64_0_b1.zip For details of what's in the release, see < http://www.boost.org/users/history/version_1_64_0.html>. Note that the links to files on this web page are for the final release - use the link above to get the beta files. There are also pre-built libraries provided by Tom Kent here: <https://dl.bintray.com/boostorg/beta/1.64.0.beta.1/binaries/> Please download the beta, give it a try, and report any problems you encounter. Thanks, -- 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

11 26

Going insane trying to build boost for android
by Robert Dailey 26 Mar '17

26 Mar '17

How many months has it been of lost google searching, trying to beat b2 into submission. I have no idea at this point how to build boost for Android. Really hoping I get some help here... So to start, here are the versions I'm using: - Android NDK r14b - Boost 1.63.0 I'm doing all of this on Windows 10, through command prompt. I want to use clang and libc++ to build boost for API 15. I figure the easiest way is to generate a standalone toolchain using the NDK, so I did that first: > %ANDROID_NDK%\build\tools\make_standalone_toolchain.py --arch arm --api 15 --stl libc++ "C:\android\_toolchains\arm-api-15" This generated the appropriate toolchain (I think). I then temporarily added this location to PATH: > set PATH=C:\android\_toolchains\arm-api-15\bin;%PATH% Then I ran bootstrap: > bootstrap.bat --with-toolset=clang Then I tried to build boost itself: > b2 --toolset=clang cxxflags="-stdlib=libc++ -std=c++14" threadapi=pthread --prefix=..\boost_android_arm --builddir=./ target-os=linux define=BOOST_FILESYSTEM_VERSION=3 --without-python link=static runtime-link=shared threading=multi variant=release install -j8 However I get failures when it tries to run the clang command: 'C:\code\_third_party\boost_1_63_0\\clang38++.exe' is not recognized as an internal or external command I'm not sure why it's appending that absolute path (that's where my current directory is set to, and where boost source is). It should just be trying to use "clang++" but doesn't look like it is. >From the output, it looks like it's trying to use clang correctly I think: "clang++" -c -x c++ -stdlib=libc++ -std=c++14 -O3 -Wno-inline -Wall -pthread -stdlib=libc++ -std=c++14 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG -I"." -o "bin.v2\libs\wave\build\clang-linux-android\release\link-static\target-os-linux\threadapi-pthread\threading-multi\cpplexer\re2clex\aq.o" "libs\wave\src\cpplexer\re2clex\aq.cpp" Am I going about this all wrong? How in the heck can I build boost for android using the settings I specified above?

2 4

[SIMD] Pre-review questions
by Artyom Beilis 26 Mar '17

26 Mar '17

Hello, I have several questions regarding Boost.SIMD (for pre-review) 1. What is boost::simd::pack::storage_type I can't find it in documentation. Is it the "native register" like __m128i for pack<int,4>? If the answer is no, how do I get access to underlying type? 2. I can't find in documentation how to performs casts between different types: I see in docs split_low (actually after I grepped for _mm_unpacklo) but I failed to find how to use one - there is no documentation regarding conversion/casting operation or at least I failed to find one. 3. Is there more convenient way to perform basic saturated operation for example if I want to calc abs diff of two bs::pack<unsigned char,16> values a,b I need to write bs::saturated_(be::minus)(a,b) + bs::saturated_(bs::minus)(b,a) It is quite inconvenient especially when most of operations you want to do are saturated. 4. Why Boost.SIMD is restricted to C++11? Most of the stuff is implementable withing C++2003, it severely limits the usability of the library for existing projects that can't trivially switch to new C++ standard (and there are too many in the "real world" industry) Thanks, Artyom

2 3

Boost Logo usage questions
by Antony Polukhin 26 Mar '17

26 Mar '17

Hello, What are the rules for the Boost logo usage? Can I use the Boost logo on a cover of the Boost related book ? What are the permissions for the library logos (for example https://github.com/boostorg/test/blob/develop/doc/html/images/boost.test.lo… )? -- Best regards, Antony Polukhin

1 0

[asio]ssl::detail::stream_core is accessed after destruction
by Takatoshi Kondo 26 Mar '17

26 Mar '17

Hello, I'm using Boost.Asio. I compiled some TLS client with clang address sanitizer. (I attached the result the last part of this mail.) It indicates that the following `expires_at` member function calling is bad: https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… So I insert debug print "stream_core() address" to the constructor of ssl::detail::stream_core https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… "~stream_core() address" to the destructor, https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… and "io stream_core address of core_" to `expires_at` calling point: https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… And then, I got the following result: stream_core() 0x6120012beb60 constructor ~stream_core() 0x6120012ca6e0 connected. previous session = false stream_core() 0x6120012ba060 ~stream_core() 0x6120012beb60 destructor io stream_core 0x6120012beb60 call Is seems that `expires_at` at https://github.com/boostorg/asio/blob/boost-1.63.0/include/boost/asio/ssl/d… is called after core_ 's destructor is called. The problem happens a part of big project. The client connects to the server as TLS-stream, then server shutdown the stream, then client connects again. The program does the sequence repeatedly. The error happens the client side. I'm trying to write a minimal and complete code that reproduces the problem, but not yet. So I report the result only as the first report. The result of clang address sanitizer ---------------------------------------------------------------------------------- SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/boost/asio/basic_deadline_timer.hpp:344:27 in boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::expires_at(boost::posix_time::ptime const&) Shadow bytes around the buggy address: 0x0c248024fd20: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x0c248024fd30: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c248024fd40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c248024fd50: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x0c248024fd60: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd =>0x0c248024fd70: fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd 0x0c248024fd80: fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa 0x0c248024fd90: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c248024fda0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c248024fdb0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa 0x0c248024fdc0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11437==ABORTING ---------------------------------------------------------------------------------- heap use after free occurs the following code: ---------------------------------------------------------------------------------- ==11437==ERROR: AddressSanitizer: heap-use-after-free on address 0x6120012bebb0 at pc 0x000000749b30 bp 0x7ffccc310470 sp 0x7ffccc310468 READ of size 8 at 0x6120012bebb0 thread T0 #0 0x749b2f in boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::expires_at(boost::posix_time::ptime const&) /usr/include/boost/asio/basic_deadline_timer.hpp:344:27 #1 0x748e21 in boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::write_op<boost::asio::mutable_buffers_1>, boost::asio::detail::write_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, mqtt::endpoint<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::io_service::strand, std::mutex, std::lock_guard>::write_completion_handler, boost::asio::detail::is_continuation_if_running> > >::operator()(boost::system::error_code, unsigned long, int) /usr/include/boost/asio/ssl/detail/io.hpp:260:32 #2 0x7590e7 in boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >,boost::asio::ssl::detail::write_op<boost::asio::mutable_buffers_1>, boost::asio::detail::write_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, mqtt::endpoint<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::io_service::strand, std::mutex, std::lock_guard>::write_completion_handler, boost::asio::detail::is_continuation_if_running> > > >::operator()(boost::system::error_code const&, unsigned long, int) /usr/include/boost/asio/impl/write.hpp:269:9 Thanks, Takatoshi Kondo

1 0

Re: [boost] Formal Review Request: mp11
by Bjorn Reese 25 Mar '17

25 Mar '17

On 03/17/2017 03:06 PM, Peter Dimov via Boost wrote: > https://github.com/pdimov/mp11/ A few comments... Most algorithms take the typelist as the first argument, but others do not, e.g. mp_transform<F, L...>. If possible, I would like to see all algorithms take typelist as the first argument. It looks like the current order is dictated by the requirements of mp_tranform_impl. Would it be possible to swap the types where the algorithm is declared? For example: template<class L, template<class...> class F> using mp_transform = typename detail::mp_transform_impl<F, L>::type; Apropos mp_transform, would it be possible to extend it such that we can pass a type-trait directly to it? For example: using const_list = mp_transform<std::add_const, typelist>; instead of using std::add_const_t. The reason I ask is that I have lots of my own domain-specific type-traits that does not come with a _t version, so this is mainly for convenience. The reference documentation is a bit terse and obscure. For example, the documentation for mp_find tells us in a convoluted way that it returns the index of a type in a typelist. It could also mention that it is the dual algorithm to mp_at, which returns a type at an index in a typelist.

3 9

I want to hire you to write some docs!
by Vinnie Falco 25 Mar '17

25 Mar '17

I'm interested in hiring someone for a contract to finish up the NuDB documentation (repository is here: https://github.com/vinniefalco/NuDB) Its not a tremendous amount of work but I don't want to shift gears from Beast, and this could be a launching point for future doc work. Feel free to reach out to my email, its listed on my GitHub page (https://github.com/vinniefalco) Thanks!!!

1 0