November 2016 - Boost - lists.preview.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

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

19 Jun '17

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

2 2

[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

[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

[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

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

12 Mar '17

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

8 19

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

04 Mar '17

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

2 1

[teeks] Missing winerror.h for MSVC-9
by Andrey Semashev 17 Feb '17

17 Feb '17

Hi, I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example: http://www.boost.org/development/tests/develop/developer/output/teeks99-09b… I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine. Could this be a tester configuration issue? Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with the error of 'cl' not being found.

3 14

[Fit] Update: Request for feedback
by Paul Fultz II 06 Feb '17

06 Feb '17

Hi, I have made a lot of updates to the Fit library based on the changes suggested during the review earlier this year. I have also improved the documentation. I have expanded on the introductory materials and have add a lot more cross-referencing. The documentation can be found here: http://fit.readthedocs.io <http://fit.readthedocs.io/> Let me know of any feedback about the library either here on the mailing list or on Github issues. Thanks, Paul

4 9

[regression] Are tests not running?
by Andrey Semashev 31 Jan '17

31 Jan '17

Hi, Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?

6 16

Why is this message in Spam?
by Olaf van der Spek 26 Jan '17

26 Jan '17

Hi, > Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication. Learn more I think this list isn't configured properly.. and this causes some messages to end up in Spam consistently.. Who's responsible for the mailing list infrastructure? Gr, -- Olaf

7 12

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 21 Jan '17

21 Jan '17

Hi, The regression matrix in develop of Boost.Geometry contains many new compilation failures due to: 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' 2): ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? ar & serialization::make_array(data_, s);and a The master is still OK. Can this be solved? Regards, Barend

6 9

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[1.63.0] Master is closed for beta release + release notes
by Daniel James 10 Dec '16

10 Dec '16

Hello everyone, The master branch is now closed for the beta release. Please can you add any remaining entries to the release notes, either by emailing me, or by creating a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… To do so, click on the little pencil icon at the top right of the code. thanks, Daniel

4 3

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 07 Dec '16

07 Dec '16

>boost.asynchronous looks to have many of the same features/functionality as HPX. >Can I ask why you chose to reimplement futures/lightweight thread pools/parallel STL/etc, >rather than working on improving HPX to suit your needs? I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds. The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion. The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both. >JB >Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC Guys" :) . No hard feeling. I'm grateful for participation and the chance to explain the underlying ideas of the library. Thanks, Christophe

4 25

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 06 Dec '16

06 Dec '16

> The regression matrix in develop of Boost.Geometry contains many new > compilation failures due to: > > > 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' > > 2): > ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: > ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? > ar & serialization::make_array(data_, s);and a > > > The master is still OK. > > Can this be solved? Ping! This is still the case! Robert, can you explain this? It is (of course) not only geometry failing, also ublas or (if there are) other libraries with ublas dependencies: http://www.boost.org/development/tests/develop/developer/numeric-ublas.html All yellow! Thanks, Barend

3 8

Re: [boost] [process] Formal Review starts today, 27 October
by Bjorn Reese 04 Dec '16

04 Dec '16

On 10/27/2016 08:26 AM, Antony Polukhin wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance I withhold judgement for now to give the author an opportunity to respond. At the moment I am unsure whether to vote for conditional acceptance or rejection. > - Your knowledge of the problem domain Advanced on Unix. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have a couple of serious concerns. My first concern is about the use of tagged arguments, and especially the redirection operators, in constructors. Instead I propose that the library uses the Named Parameter idiom (see [1], not to be confused with what Niall labelled "tagged name parameter" idiom.) The bp::child object should not execute in the constructor, but rather via operator(). That way we can use the named parameter idiom to build up redirections and similar modifications. For example: auto compile = bp::child("c++").output(bp::null); compile("main.cpp"); // Executes My second concern is about deadlocking. The FAQ shows two ways of deadlocking. I would expect the latter (the ls example) to work without further ado because that is how any newcomer would write their code. My third concern is about the chaining of pipes between processes. The tutorial shows an example where the output of the nm command is forwarded to the c++filt command. However, the forwarding is not done directly from the nm process to the c++filt process, but goes via the parent process. This can incur a performance degradation when nm generates much output. Is it possible to chain them directly? Besides "nm myfile | c++filt" that is. I also have the following minor comments / questions. Is it possible to redirect stderr to stdout? (like 2>&1). The reference documentation only mentions this under asynchronous pipe output. The bp::starting_dir should be renamed to bp::current_path to be consistent with Boost.Filesystem. Consider renaming bp::spawn to avoid confusion with boost::asio::spawn which is how you launch coroutines with Boost.Asio. I am missing a this_process::get_id() function to return the current process identifier. > * Implementation My major concern with the implementation is that the library is only header-only, so I cannot compile it as a static library if I wish to. There are several Boost header-only libraries that allows you to do that. The reason why I find this important for Boost.Process is because I want to avoid getting platform-specific C header files included into my project when I include a Boost.Process header. The library should throw its own process_error exception which inherits from system_error, similar to Boost.Filesystem. I did not investigate the implementation in greater detail. > * Documentation The documentation is lacking an entire chapter with an overall description of the library and the concepts used. For instance: * What are processes and pipes? * What are the possible invocation mechanisms? Some of this is mentioned in the Design Rationale, but that is not the place where developers seek their information. * How to set search paths or the current working directory. * How to use environment variables. * this_process Tutorial / Synchronous I/O: What is the default behaviour when I/O redirections are not specified? Tutorial / Asynchronous I/O: Consider including an example with boost::asio::spawn as a way to obtain the yield context. Reference / child: Does not mention how the life-time of the object and the child process are related. For instance, the documentation on the destructor only mentions that it is a destructor. Reference / cmd: bp::cmd will parse the input string as a sequence of space-separated arguments. Is it spaces or whitespaces? Is it possible to have escapes for arguments that do contain spaces? > * Tests Did not investigate. > * Usefulness A process library is a very useful addition to Boost. > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? Did not try. > - How much effort did you put into your evaluation of the review? About 4-5 hours (one of which was gratuitously donated by daylight saving time.) [1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Parameter

11 49

[poly_collection] Request for comments: fast polymorphic collections
by Joaquin M López Muñoz 02 Dec '16

02 Dec '16

A couple of years ago I wrote two blog entries about high-performance data structures for polymorphic objects: http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html that spurred some interest in the community. Now I've had the time to turn these ideas into something resembling a full-fledged library: https://github.com/joaquintides/poly_collection http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html and I'd be very grateful if people could give their opinion on usefulness, design, etc. so as to determine potential interest in an eventual official submission to Boost. Thank you, Joaquín M López Muñoz

6 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>After having a deeper dive into the documentation and examples, one >pattern I see popping up quite >frequently is this: >future<R> fut = my_promise.get_future(); >post_callback(some_work, [this](expected<R> r) { >this->my_promise.set_value(r.get()); }); >return fut; This is simply to make examples easier to run (it finishes the example). It demonstrates that the only one which blocks in an application built on Asynchronous is main(). This might be more confusing than useful and I probably should get rid of this. >Is there any performance/usability drawback from this (might have gotten >the syntax wrong here): >return post_future(pool, some_work); > >Why is the former to be preferred to the latter, or vice versa? post_future is the preferred for simple applications or examples. It is similar to std::async (without the problem of blocking futures and with different continuations). post_callback is the design the library seeks to promote for bigger applications: post a task to a threadpool, get a callback posted to the queue of the caller's thread world. >Regarding the documentation overall, >it seems to miss a proper reference section. >For example, boost::asynchronous::expected is used almost >everywhere, but not documented. My bad. Will be corrected. Thanks, Christophe

2 2

Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

Dear Community, The Asynchronous library is now listed in the Boost Library Incubator ( http://blincubator.com/bi_library/asynchronous-2/?gform_post_id=1654) I took a lot of time since first presenting it in C++ Now 2014 in order to extend the scope and intensively test the library. The library has been in use in production code for already 1.5 years, has survived billions of calls and usage 24/7, so its core is stable and quite tested. All algorithms have not been used though so that bugs are possible there. The reason for using the Incubator is, the library is quite big and 2 weeks review will not be sufficient so I hope for comments, discussions or pre-reviews earlier on. Asynchronous is first of all an architecture tool. It allows organizing a complete application into Thread Worlds, each world having the possibility to use the same or different threadpools for long-lasting tasks. The library provides an implementation of the Active Object pattern, extended to allow many Active Objects to live in the same World. It provides several Threadpools and many parallel algorithms making use of them. And most important of all, it allows simple, blocking-free asynchronous programming based on thread-safe callbacks. It also provides very useful logging and HTML diagnostics (see https://htmlpreview.github.io/?https://raw.githubusercontent.com/henry-ch/a…) to allow better understanding of code. I look forward to an interesting and lively discussion. Christophe

6 7

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>I'm trying to digest the docs for this monster work. > >One things that strikes me immediately is that the doc preparation >does not use code snippets, and so code is in boring old >black'n'white rather than colored syntax. >For me, that makes it significantly harder to read (and understand) the code examples. Ok, I'll see if I can improve this. >It also means that one doesn't have the assurance that 'What You See is What Compiles'. For most features, the doc provides a link to an example, which I regularly compile. >(I've also having trouble finding things in all the plentiful 'good stuff'. >But that's a common (and largely still unsolved) >problem with all documentation.) >Paul Please let me know what is the "good stuff" for you and I'll make it more visible. Cheers, Christophe

2 1

[compute] Remove boost::chrono lib dependencie
by Viktor Sehr 01 Dec '16

01 Dec '16

Hi, Would it be possible to remove the dependency for boost/chrono is boost/compute/detail/duration.hpp. As it already supports std::chrono via a macro, couldn't the inclusion of boost/chrono.hpp be excluded? As it is now, boost compute is dependent on having libboost_chrono-vc140-mt-gd-1_62.lib built. /Viktor

4 4

[release] Boost 1.63.0 Beta 1
by Marshall Clow 29 Nov '16

29 Nov '16

The first beta packages for 1.63.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.63.0.beta.1/> The SHA256 checksums are as follows: 3dbc1bca10941710755c13a00b1ae56d2d37fe90bbadcf9746203194f9d33e3a boost_1_63_0.7z c8b986fd57e436fd88dbc70e51d3e21efa2be3bdf835fa499b2cf6c0a8cc2985 boost_1_63_0.tar.bz2 745d99e4be9c0f324ec7ba15b7d228fd780067f2e8aeae2f16660a4cf6e6a051 boost_1_63_0.tar.gz e66bd6e2f637148c314398b92bc1f3cbdc777ee282f9de7885697afad3d9c202 boost_1_63_0.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

12 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Vicente, >> In theory, the standard version would suffice, except for Thread. >> Boost.Thread provides interruption points, which the standard does not. >> With the standard version, I would not be able to offer task interruption. >Could you explain why task interruption is associated to thread >interruption? Ah already implementation details :) Tasks are executed in schedulers (uisually threadpools), which manage 1 to n threads. To interrupt a task from outside, the library interrupts the thread running the task. To be exact, the task will be interrupted the next interruption point in encounters. The thread executing the task does not terminate but instead recovers and pops the next task from its job queue. >> I rely for the other parts also on Boost because the standard version had >> bugs on earlier versions of compilers, and quite some projects are still >> stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain >> using Boost (which also happens to be faster than the standard, at least on >> my tests). >> >Whow, glad to hear Boost.Thread is working for you Henry. It is. I got no problem whatsoever. >I believe that Michael is however right. Boost libraries restricted to >C++11 should use the standard library as much as possible. Sure. At the moment I have no way around Boost.Thread though. If that changes, I'll probably want to switch to standard. The performance issue for the clock is not a huge one and by that time, the older compilers will hopefully have vanished. I could provide a macro to switch between boost / std. If one needn't interrupt tasks, the library would make no use of boost at all. >It would be great to have a specific C++11 (language and standard >library) version of your library. Well, if there is interest, why not? >Good luck with the review, >Vicente >P.S. I've in my todo's list implement thread interruption on top of the >standard as Anthony showed in his book, but I have no time to work on >this now. Oh, it would be great. This really is a fantastic feature. Thanks, Christophe

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Michael, >Thank you for submitting this library to the the incubator in >preparation for a review. I saw your presentation in 2014 >and I believe that this library solves a common problem. >My first question: I see that the library is listed as C++11 and also >has dependencies on Boost.System, Boost.Thread, Boost.Chrono, >and Boost.DateTime. Much of the functionality provided by those >Boost libraries is now part of the C++11 or C++14 standard. >Can you comment on the specific Boost dependencies >and if the standard versions would suffice? A good question which deserves a rationale, which I will add. In theory, the standard version would suffice, except for Thread. Boost.Thread provides interruption points, which the standard does not. With the standard version, I would not be able to offer task interruption. I rely for the other parts also on Boost because the standard version had bugs on earlier versions of compilers, and quite some projects are still stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain using Boost (which also happens to be faster than the standard, at least on my tests). HTH, Christophe

2 1

[ssl] SSL handshake takes forever sometimes
by Shuchen He 28 Nov '16

28 Nov '16

Hi, I have an application written in boost with SSL. I noticed that when the client network is down for a while and come back again. The SSL handshake sometimes take forever. I tried to kill the client application and run it again, the problem still there. The only way to make it work again was to reboot my client device. I'm using boost 1.60 on the client side and 1.58 on the server side. The SSL handshake code was copied from Boost SSL server and client example I modified a bit to suit my application needs. Does anyone experience the similar issue? If so, can you please let me know how do you fix it? It would be much appropriated if you could help me out on this issue. Below is the SSL handshake code. chat_client(boost::asio::io_service& io_service, boost::asio::ssl::context& context, tcp::resolver::iterator endpoint_iterator) : io_service_(io_service), socket_(io_service, context) { filesize_=0; isfileopen_=false; socket_.set_verify_mode(boost::asio::ssl::verify_peer); socket_.set_verify_callback( boost::bind(&chat_client::verify_certificate, this, _1, _2)); boost::asio::async_connect(socket_.lowest_layer(), endpoint_iterator, boost::bind(&chat_client::handle_connect, this, boost::asio::placeholders::error)); } bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx) { char subject_name[256]; X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle()); X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256); log_time(); fprintf(logfile,"%s: Verifying %s\n",logtime.c_str(), subject_name); return preverified; } void handle_connect(const boost::system::error_code& error) { if (!error) { socket_.async_handshake(boost::asio::ssl::stream_base::client, boost::bind(&chat_client::handle_handshake, this, boost::asio::placeholders::error)); } else { log_time(); fprintf(logfile, " %s Connect to server failed: %s\n ",logtime.c_str(), error.message().c_str()); fflush(logfile); delete this; } } void handle_handshake(const boost::system::error_code& error) { if (!error) { ssl_handshake_ok=1; do_read_header(); } else { log_time(); fprintf(logfile,"%s: Handshake failed:%s\n ",logtime.c_str(), error.message().c_str()); } }

1 0

[poly_collection] request for help at performance testing
by Joaquin M López Muñoz 28 Nov '16

28 Nov '16

Hi, Some days ago I published the first version of (candidate) Boost.PolyCollection at https://github.com/joaquintides/poly_collection Performance tests are available at http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… but GCC and Clang were run in a Travis VM and the resulting figures are noisy and not sufficiently accurate. I'm looking for volunteers willing to run the performance suite in one or more of the following environments: * Recent GCC, 32 bit * Recent GCC, 64 bit * Recent Clang 32 bit * Recent Clang, 64 bit The full suite in one environment takes 1.5-2h to execute. If you're interested, please contact me privately (so that we don't pollute the mailing list) and I'll provide you with further instructions on how to do the testing. Thank you! Joaquín M López Muñoz

1 0

[iterator] Orbiting iterators
by Jeremy Murphy 27 Nov '16

27 Nov '16

Hi, just wondering what the mood in Boost.Iterator is for new features? At work we recently found use for an orbiting iterator, specifically a circular one, which effectively wraps at the start/end of a bounded range. (The domain is digital signal processing.) Implementation details aside, does this feature sound desirable to the library? I call it an "orbiting" iterator because it is a specific (and useful) case of the more general rho-shaped orbiting iterator. The theory behind it is in chapter 2 of Elements of Programming, which happens to be the free sample chapter available: http://elementsofprogramming.com/032163537X_Sample.pdf#page=6 Anyway, if there is interest, I'll make a pull request. Cheers. Jeremy

6 10

Re: [boost] [beast] Separation between parse and generation and asio
by Vinnie Falco 24 Nov '16

24 Nov '16

On Wed, Nov 23, 2016 at 10:45 PM, Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> wrote: > I'm trying Beast with avr-gcc to see how much footprint it would take > on embedded applications. Thank you for your interest in Beast! > Unfortunately, stream_concepts uses asio > types, which requires asio include which requires network includes > which will obviously fail in most microcontrollers. > > Would it be possible to make parse and read implementation less > dependent on each other? I see what you mean. Yes, I believe I can do that - would you mind creating a new issue here? https://github.com/vinniefalco/Beast/issues Thanks!

1 0

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Niall Douglas 24 Nov '16

24 Nov '16

Dear Boost, I am hoping to bring Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports, into the Boost peer review queue by March 2017 followed shortly thereafter by an ACCU talk in April if my talk proposal passes their programme committee. To that end, I've written an explanation and a sort of tutorial explaining the history and purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd greatly appreciate if people could tell me: 1. Does it make sense? 2. Do you think you could use Outcome in your own code after reading it? 3. Do you think you would want to use Outcome in your own code after reading it? 4. Are there any missing parts which are showstoppers? My thanks in advance. Be aware the install stuff described at the start doesn't work yet. The reference documentation is also quite patchy thanks to doxygen not understanding CRTP. All that stuff and a fair bit more remains to fix before it's ready to enter the Boost peer review queue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 14

[beast] Separation between parse and generation and asio
by Felipe Magno de Almeida 24 Nov '16

24 Nov '16

Hello, I'm trying Beast with avr-gcc to see how much footprint it would take on embedded applications. Unfortunately, stream_concepts uses asio types, which requires asio include which requires network includes which will obviously fail in most microcontrollers. Would it be possible to make parse and read implementation less dependent on each other? Boost.Spirit x3 works very well on microcontrollers. I'd expect a different type for messages which could actually receive iterator pairs for strings with Beast might give a very good option for HTTP/WS implementation on microcontrollers. Regards, -- Felipe Magno de Almeida

1 0

[sort] Parallel sorting sub-library mini-review conclusion
by Christophe Henry 22 Nov '16

22 Nov '16

> I would like to know the memory used and the best, >normal and worst case of the Asynchronous sorting algorithms. The sort versions are mergesort so they use double memory. The quicksort versions require no extra memory while partitioning. When they degrade after some partitioning iterations, they require the extra memory used by the underlying sort algorithm (spreadsort, std:sort, intro_sort, etc.). Thank you Francisco for this interesting library which I shamelessly used into my own ;-) It's probably a bit late but I vote for acceptance. Cheers, Christophe

2 1

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

>> >> OTOH the single-threaded ones are interesting, especially the stable_sort >> and intro_sort for cases where usage of spreadsort is not possible. >> >I challenge you to find a sorting problem where it isn't possible to use >spreadsort. string_sort can sort anything that std::sort can; > you just need to convert the sort key comparison sequence into a sequence of bytes > and feed string_sort the correct functors. That said, it may not be >efficient to sort some problems with string_sort, >and it'll probably be too much work to be worth the effort for many problems. This is what I meant. Sorry for the lack of precision. I'll add it to my performance tests, it might be an interesting variant as the algorithm is really fast. >> >> A short summary: >> >> 100000000 uint64_t elements already sorted: >> Boost parallel sort : 0.064965 secs >> >> Asynchronous parallel sort : 0.0167134 secs (same with other >> algorithms) >> >> Asynchronous provides a special optimization for this case. >> >If this optimization is practical to incorporate in Boost parallel sort, >it is a common case and your solution seems noticeably faster, >so I would like Francisco to consider it. That said, .06s isn't bad. Sure. >> >> I added this one: >> 100000000 uint64_t elements reverse sorted >> >> Boost parallel sort : 0.581381 secs >> >> Asynchronous parallel sort : 0.0478701 secs >> >> Asynchronous provides a special optimization for this case. >> I this the library should do it too. This one is pretty common and a >> popular DOS attack. >> > This optimization would be nice to have, if it's cheap. A parallel reverse is in O(n) so it's cheap compared to a sort. >> >> 100000000 uint64_t elements randomly filled >> >> Asynchronous parallel quickspreadsort: 0.587432 secs >> Asynchronous quick_intro_sort : 0.728393 secs >> >> This mixing of quicksort degrading into a spreadsort works here best. >I find this algorithm interesting; Frankly, there is nothing special. It's simply a parallel partition, which degrades into a "normal" parallel merge sort (in this case spreadsort) after a while. >have you considered using MSD radix-based sorting to break up the data > for the threads in parallel? >For example, take T threads, have each thread take 1/T of the data > and bucket it into N MSD-based buckets (just like Spreadsort), >where T < N <= ~2^11, then merge the equivalent buckets, >and as you merge them hand them off to another thread to sort. >This will probably divide better if you find the max and min before bucketing >using a parallel min/max search. I admit I didn't. But it sounds really interesting and I think I'll have a go at it. I'm not a sort expert though. I approached this from the parallel perspective. >> 10000000 strings randomly filled >> >> OMP parallel sort : 1.05803 secs >> Boost parallel sort : 0.933055 secs >> >> OMP parallel stable sort : 1.12269 secs >> Boost sample sort : 0.889216 secs >> Boost parallel stable sort : 1.56564 secs >> >> Asynchronous parallel quickspreadsort: 0.788856 secs >> Asynchronous quick_intro_sort : 0.893652 secs >> >> Asynchronous parallel stable sort : 1.23495 secs >> Asynchronous boost::stable sort : 1.21817 secs >> >> Similar results. >> >> >> Let's move on to big objects: >> >> 1562500 elements of size 512 randomly filled >> H E A V Y C O M P A R I S O N >> >> OMP parallel sort : 0.308923 secs >> Boost parallel sort : 0.342992 secs >> >> Asynchronous parallel_quicksort : 0.246709 secs >> Asynchronous quick_intro_sort : 0.269666 secs >> >> Both quicksorts are best, with a slight advantage to intro_sort. >> >> The light comparison is similar. >> >Do we have your permission to copy and/or adapt your quick_intro_sort >algorithm into the Boost.Sort library? Please feel free to copy whatever might be useful. The library has a Boost license as it's intended for inclusion in Boost.I also took the freedom of adding the single-thread versions of Fernando's algorithms as basis for my parallel versions. The algorithm is quite simple. It's the same as quick_spreadsort, a quicksort which degrades into Francisco's intro_sort after some iterations. I just found it interesting to add a wrapper to Francisco's algorithm for the mini-review. It was just a quick test (no time for cleverer algorithms) but I'm pretty satisfied with the result and I'll keep these versions. >How is the worst-case performance relative to Francisco's library? The sort versions have O(n log n) like any merge sort. The quicksort have O(n log n) to O(n^2) as expected from a quicksort. Cheers, Christophe

1 0

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi, > The threads are created only 1 time*. Have I missed something? I checked sample_sort and I saw several sets of calls to std::async which is likely to create and destroy threads several times. >*parallel_sort, sample_sort* : this algorithm is commonly accepted as the >fastest for the parallel stable sort. >The implementation is *notoriously faster than the provided by the GCC compiler* >( based on Open MP ) using less memory. TBB don?t >provide parallel stable sort, and only have an experimental code in their web pages Indeed, I found it highly interesting. Cheers, Christophe

1 0

[release] Boost 1.63.0 - fixes
by Oliver Kowalke 22 Nov '16

22 Nov '16

unfortunately beta 1 does not contain fixes from boost.context and boost.fiber. could you add the fixes to the 1.63 release, please? Oliver

3 4

[sort] Parallel sorting sub-library mini-review starts tomorrow, 11 November
by Steven Ross 22 Nov '16

22 Nov '16

Dear Boost community, The mini-review of Francisco Tapia's Parallel sorting library begins tomorrow November 11, and ends November 20th. The purpose of this review is to assess whether the sub-library is useful and up to Boost software standards. If the Boost community agrees on both, Francisco and I will integrate it into the existing Boost.sort library as a separate sub-library from Spreadsort. In doing so we'll integrate the documentation with the existing documentation for Boost.Sort, making it more consistent. If you review Francisco's library, please make sure you're using a compiler that supports C++11, and answer each of these questions: 1. Were you able to run it and see accurate and fast results? Please specify your compiler, OS, and processor type, and any problems (or slowdowns) encountered. 2. Would you use this library if accepted? Why or why not? 3. What is your evaluation of the design? 4. What is your evaluation of the implementation? 5. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? The library is here: https://github.com/fjtapia/sort_parallel This library provides both stable and unstable sorting algorithms, in single threaded and parallel versions. - All the algorithms have average and worst case runtime of O(NLogN). - These algorithms do not use any other library or utility. To compile and run these you will need a *C++11 compliant compiler.* - *This library is *include only, only requiring* the files in the boost/sort/parallel folder, with no external dependencies.* - The algorithms use a comparison object, in the same fashion as std::sort, defaulting to the std::less object, which uses the < operator internally for comparisons. - The algorithms are exception safe, meaning that the exceptions generated by the algorithms guarantee the integrity of the objects to sort, but not their relative order. If the exception is generated inside the objects (in the move or in the copy constructor) the results can be unpredictable. The library has a a new parallel_sort algorithm *( internally named Block Indirect)*, for processors connected with shared memory*,* invented for the library. This new algorithm combines the speed of algorithms like the GCC parallel sort (based on OpenMP), or the Microsoft parallel buffered sort, with the small memory consumption of algorithms like the TBB sort and the Microsoft parallel Sort. Results from running on an I7 5820 with 12 threads: GCC parallel_sort 1,25 secs 1560 MB TBB parallel_sort 1,64 secs 783 MB Boost parallel_sort 1,08 secs 786 MB In a separate repository (because it uses licence-restricted software like TBB and Microsoft parallel sort, and can’t be included in the Boost library), you can find all the code needed to run the benchmarks, the library code, the benchmark programs, and shell scripts to compile and run it on your machine in Linux and Windows. For the Linux benchmarks you will need to install TBB. (https://github.com/fjtapia/sort_parallel_benchmark) We look forward to your feedback!

4 5

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi Boost Community, I did not manage yet to write a full review. One week is a bit short so a few more days will be necessary. I provide some performance tests first. To check the library performance, I pitted it against my own versions of a parallel mergesort and quicksort provided by the asynchronous library ( https://github.com/henry-ch/asynchronous) which is now ready for review, so we have a stable state for testing. I also added a parallel version inside the asynchronous library using Francisco's single-thread implementations to compare with his parallel ones. I tested on a i7-5960X. Due to time limits, I could not test on more interesting NUMA platforms (I did not get the reviewed library to compile for my KNC) so the tests do not pretend to have value outside the i7 architecture. I linked with tbb_malloc_proxy to limit memory influence. In a nutshell. I'm not a big fan of the parallel version of the algorithms. It seems to be based on std::async, so that a lot of threads are started and joined at every call. I would suggest using a threadpool. OTOH the single-threaded ones are interesting, especially the stable_sort and intro_sort for cases where usage of spreadsort is not possible. Cheers, Christophe A short summary: 100000000 uint64_t elements already sorted: OMP parallel sort : 0.390899 secs Boost parallel sort : 0.064965 secs OMP parallel stable sort : 1.06128 secs Boost sample sort : 0.0695357 secs Boost parallel stable sort : 0.0662401 secs Asynchronous parallel sort : 0.0167134 secs (same with other algorithms) Asynchronous provides a special optimization for this case. I added this one: 100000000 uint64_t elements reverse sorted OMP parallel sort : 0.317039 secs Boost parallel sort : 0.581381 secs OMP parallel stable sort : 1.06448 secs Boost sample sort : 0.524746 secs Boost parallel stable sort : 0.73036 secs Asynchronous parallel sort : 0.0478701 secs Asynchronous provides a special optimization for this case. I this the library should do it too. This one is pretty common and a popular DOS attack. 100000000 uint64_t elements randomly filled OMP parallel sort : 1.03594 secs Boost parallel sort : 0.796447 secs OMP parallel stable sort : 1.28601 secs Boost sample sort : 0.818954 secs Boost parallel stable sort : 1.13604 secs Asynchronous parallel quickspreadsort: 0.587432 secs Asynchronous quick_intro_sort : 0.728393 secs This mixing of quicksort degrading into a spreadsort works here best. The parallel adaptation of intro_sort is not bad either and best of other library algorithms. Asynchronous parallel stable sort : 1.26141 secs Asynchronous boost::stable sort : 0.804814 secs Interesting. The stable version of the library easily beats std::stable_sort I used until now. 10000000 strings randomly filled OMP parallel sort : 1.05803 secs Boost parallel sort : 0.933055 secs OMP parallel stable sort : 1.12269 secs Boost sample sort : 0.889216 secs Boost parallel stable sort : 1.56564 secs Asynchronous parallel quickspreadsort: 0.788856 secs Asynchronous quick_intro_sort : 0.893652 secs Asynchronous parallel stable sort : 1.23495 secs Asynchronous boost::stable sort : 1.21817 secs Similar results. Let's move on to big objects: 1562500 elements of size 512 randomly filled H E A V Y C O M P A R I S O N OMP parallel sort : 0.308923 secs Boost parallel sort : 0.342992 secs Asynchronous parallel_quicksort : 0.246709 secs Asynchronous quick_intro_sort : 0.269666 secs Both quicksorts are best, with a slight advantage to intro_sort. The light comparison is similar. My test code (the modified benchmark.cpp provided by the library): https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test… The full test results: https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test…

3 2

[process] daemon ideas
by Dracon Pern 21 Nov '16

21 Nov '16

I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated. Thoughts? Thanks, -Eric

4 3

Re: [boost] [iterator] Orbiting iterators
by Jeremy Murphy 20 Nov '16

20 Nov '16

Hi Steve, On 21 Nov 2016 3:01 AM, "Steve M. Robbins" <steve(a)sumost.ca> wrote: > > On Sunday, November 20, 2016 8:25:20 PM CST Jeremy Murphy wrote: > > Hi, > > > > just wondering what the mood in Boost.Iterator is for new features? At work > > we recently found use for an orbiting iterator, specifically a circular > > one, which effectively wraps at the start/end of a bounded range. (The > > domain is digital signal processing.) > > That sounds like what CGAL calls a Circulator; c.f. http://doc.cgal.org/ > latest/Circulator/classCirculator.html Right, yeah. Unfortunately I can't view the documentation properly on my phone so I'll take a look later, but I imagine the principle is the same although the interface is not. > > Implementation details aside, does this feature sound desirable to the > > library? > > I've found these handy when iterating through graph edges incident on a > vertex, when you need to start on a specific edge. It's been ages since I've > used them so I can't recall the exact use case. Makes me wonder whether > something like this already exists in boost graph. As you pointed out with CGAL, domain-specific implementations do exist. Boost.Geometry has something too. I guess I'm interested in whether this need for circular iteration can be abstracted back to the plain old iterator. Cheers. Jeremy

1 0

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Matus Chochlik 20 Nov '16

20 Nov '16

On Fri, Nov 11, 2016 at 8:27 PM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > Dear Boost, > > I am hoping to bring Boost.Outcome, a C++ 14 library providing a > factory and family of policy driven lightweight monadic > value-or-error transports, into the Boost peer review queue by March > 2017 followed shortly thereafter by an ACCU talk in April if my talk > proposal passes their programme committee. To that end, I've written > an explanation and a sort of tutorial explaining the history and > purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd > greatly appreciate if people could tell me: > > 1. Does it make sense? > Yes, the explanation is useful and does make sense. > > 2. Do you think you could use Outcome in your own code after reading > it? > > 3. Do you think you would want to use Outcome in your own code after > reading it? > I'm already using something similar in my oglplus2 OpenGL wrapper and some other projects and I really like the technique. IMO the C++ community would benefit from having something like this in Boost. In my implementation the outcome is a pair of the "real" result and an "error info" which can be more elaborate than an error code + a policy which by default throws an exception from the error info when the outcome is destroyed. The function caller can explicitly cancel the throwing and just examine the error information. All functions returning outcome can be noexcept. > > 4. Are there any missing parts which are showstoppers? > I didn't try to use your implementation, but I don't see anything obvious. But a shorter initial tutorial would be helpful. > > > My thanks in advance. Be aware the install stuff described at the > start doesn't work yet. The reference documentation is also quite > patchy thanks to doxygen not understanding CRTP. All that stuff and a > fair bit more remains to fix before it's ready to enter the Boost > peer review queue. > BR, Matus

2 1

Info on Sprout libraries (related to Boost?)
by charleyb123 . 19 Nov '16

19 Nov '16

Looking at the (very impressive) Sprout libraries that distributes using the Boost license: Welcome to the Sprout C++ Libraries <http://bolero-murakami.github.io/Sprout/docs/index.html#welcome-to-the-spro…> C++11 constexpr based Containers, Algorithms, Random numbers, Parsing, Ray tracing, Synthesizer, and others. https://github.com/bolero-MURAKAMI/Sprout ...It appears to be actively maintained, and very interesting. Anybody know the background and roadmap on these libraries (they are not in Boost now, right?) I'm particularly interesting in more 'constexpr' and compile-time libraries showing up, where C++14 (and C++17) wholly "throws-open-the-door" on what you can do at compile time (for example, see the C++14 constexpr used as a full C compiler: https://github.com/kw-udon/constexpr-8cc ) Crazy stuff. --charley

3 2

[fiber] maintenance status
by Tatsuyuki Ishi 18 Nov '16

18 Nov '16

The fiber library seems to be still updated, but I can't get into the author to do a feature proposal or request a refactor. Please take a look at this: https://github.com/boostorg/fiber/issues/89 I have pinged Oliver 3 times, and also sent some emails to his git committer addresses (he uses two identities). If you (the maintainer) are aware of this issue, please respond; I'm willing to do code contributions, but I must have some opinions about that before I get on to the work.

2 1

BOOST_NO_CXX11_HDR_CODECVT confusion
by Robert Ramey 17 Nov '16

17 Nov '16

I use BOOST_NO_CXX11_HDR_CODECVT from config.hpp in order to selectively enable code which uses the built-in codecvt facets as opposed to the boost "home brew" one we've been using for a long time. I do similar things with other macros such as BOOST_NO_CXX11_HDR_FORWARD_LIST. Problems arise when I use a recent compiler such as gcc 6.2 with the switch -std=c++03 as in "/hpc-6.2/usr/local/bin/g++" -ftemplate-depth-128 -std=c++03 -O0 -fno-inline -Wall -g -dynamic -gdwarf-2 -fexceptions -fPIC -arch x86_64 -Wno-unused-variable -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I"../../.." -c -o "../../../bin.v2/libs/serialization/test/test_iterators.test/darwin-6.2~03/debug/test_iterators.o" "test_iterators.cpp" In this ease I would expect to find that BOOST_NO_CXX11_HDR_CODECVT is defined as C++ standard does not include <codecvt> headers for versions prior to C++ 11. But the test matrix http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-… for this compilers shows that BOOST_NO_CXX11_HDR_CODECVT is NOT defined when no -std=c++03 is used. OK - I see that for gcc 6.2 the default is C++ 14 if no switch is used. So the test matrix is OK. I'm not sure what the column is meant to test as it does specify a particular version as the other columns do. So I think the test for gcc 6.2 - and all the g++/clang compiler would be improved by specifying which version of the C++ standard they are actually testing. But I still have a problem. When I use the swithc -std=c++03 I expect that BOOST_NO_CXX11_HDR_CODECVT be defined as C++ versions prior to C++ 11 don't have header <codecvt>. Same goes for other headers required only for more recent compilers. But my expectations aren't realized as BOOST_NO_CXX11_HDR_CODECVT is not defined in this case. The leads to selection of library code which invokes an #error saying that it's not supported. Perhaps definition of BOOST_NO_CXX11_HDR_CODECVT is conditioned solely on the existence of <codecvt> rather than the existence of <codecvt> and the compiler running in C++ 11+ "mode". I think this is what is messing things up for me. I might be able to work around this if I config.hpp included a macro which indicated which standard version it's intended to support. It doesn't have this. But I wouldn't need it if the BOOST_NO... worked as I would expect. Robert Ramey

3 3

MSVC opensource deployment.
by Robert Ramey 16 Nov '16

16 Nov '16

This just showed up in my junk mail box. Vcpkg updates: Static linking is now available https://github.com/Microsoft/vcpkg With 90+ libraries in its catalog, Vcpkg makes it easier to find the right open source library for Visual C++ 2015. The latest update now supports static linking. This kind of interesting: a) Does this constitute and open-source source code deployment system that perhaps we might learn from/exploit? b) I'm intrigued with the comment under "License": "Code licensed under MIT License" Boost is in this repository - I don't remember changing the Boost license. Robert Ramey

4 5

[Sort] Parallel Sorting Mini review ends November 20th (Need reviewers)
by Francisco José Tapia 16 Nov '16

16 Nov '16

Dear Boost community, The mini-review of Francisco Tapia's Parallel sorting library began in November 11, and ends November 20th. The purpose of this review is to assess whether the sub-library is useful and up to Boost software standards. If the Boost community agrees on both, Francisco and I will integrate it into the existing Boost.sort library as a separate sub-library from Spreadsort. In doing so we'll integrate the documentation with the existing documentation for Boost.Sort, making it more consistent. If you review Francisco's library, please make sure you're using a compiler that supports C++11, and answer each of these questions: 1. Were you able to run it and see accurate and fast results? Please specify your compiler, OS, and processor type, and any problems (or slowdowns) encountered. 2. Would you use this library if accepted? Why or why not? 3. What is your evaluation of the design? 4. What is your evaluation of the implementation? 5. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? The library is here: https://github.com/fjtapia/sort_parallel This library provides both stable and unstable sorting algorithms, in single threaded and parallel versions. - All the algorithms have average and worst case runtime of* O(NLogN).* - These algorithms *do not use any other library or utility*. To compile and run these you will need a *C++11 compliant compiler.* - This library is *include only*, only requiring the files in the boost/sort/parallel folder, with no external dependencies. - The algorithms *use a comparison object*, in the same fashion as std::sort, defaulting to the std::less object, which uses the < operator internally for comparisons. - The algorithms are *exception safe*, meaning that the exceptions generated by the algorithms guarantee the integrity of the objects to sort, but not their relative order. If the exception is generated inside the objects (in the move or in the copy constructor) the results can be unpredictable. The library has a a* new parallel_sort algorithm ( internally named Block Indirect)*, for processors connected with shared memory, *invented for the library*. This new algorithm combines the speed of algorithms like the GCC parallel sort (based on OpenMP), or the Microsoft parallel buffered sort, with the small memory consumption of algorithms like the TBB sort and the Microsoft parallel Sort. Results from running on an I7 5820 with 12 threads: - GCC parallel_sort 1,25 secs 1560 MB - TBB parallel_sort 1,64 secs 783 MB - Boost parallel_sort 1,08 secs 786 MB In a *separate repository* (because it uses licence-restricted software like TBB and Microsoft parallel sort, and can’t be included in the Boost library), you can find *all the code needed to run the benchmarks*, the library code, the benchmark programs, and shell scripts to compile and run it on your machine in Linux and Windows. For the Linux benchmarks you will need to install TBB. (https://github.com/fjtapia/sort_parallel_benchmark) We look forward to your feedback!

1 0

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

16 Nov '16

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

12 48

Re: [boost] [MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

On Nov 15, 2016 23:57, "Peter Dimov" <lists(a)pdimov.com> wrote: > > Bruno Dutra wrote: > >> Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0: >> >> https://github.com/brunocodutra/metal/blob/develop/.travis.yml. > > > I don't care that much for 3.9 and 4.0, but the -stdlib=libc++ option is intriguing. Does it require sudo? I just checked and libc++-dev is whitelisted on Precise images, so it shouldn't require sudo. That said, the version of libc++ available on such an old version of Ubuntu might not fit your needs (it didn't mine) so you might need to upgrade to Trusty, in which case I believe it requires sudo, because it doesn't seem to be whitelisted yet.

1 0

[fiber] destruction order fiasco
by Tatsuyuki Ishi 15 Nov '16

15 Nov '16

The fiber still makes use of the scheduling algorithm after main context exits, which is a problem for my case that puts a stack-allocated shared data to the algorithm. Some points: https://github.com/boostorg/fiber/blob/master/src/context.cpp#L52 I doubt if the schwarz counter is needed; isn't it only one? https://github.com/boostorg/fiber/blob/master/src/scheduler.cpp#L137 I don't think there's a need to wake it up; if it's sleeping, the thread is blocked and it never enters here. This is the main problem: use-after-free. Anyway, what I think is ideal is that just making the algorithm a reference and assign it from the main context. An example of this approach is Qt's Q*Application.

1 0

Re: [boost] [Boost-users] [process] Formal review results
by Bjorn Reese 13 Nov '16

13 Nov '16

On 11/09/2016 07:45 PM, Antony Polukhin wrote: > The Boost.Process library is accepted. Unconditionally? Please notice that some of the votes were conditional, and if those conditions are not met, they should be counted as no votes. > The most controversial part of the library is it's interface. Many > comments were addressing: > * passing arguments > * starting process right in `system(...)` function The comments were about starting the process in the child constructor.

4 3