- Boost - lists.boost.org

[random] Request for Additional Generators
by degski 15 Jun '17

15 Jun '17

I would like to request the addition of 2 generators to Boost.Random. xoroshiro128+ <http://xoroshiro.di.unimi.it/xoroshiro128plus.c> Web page: http://xoroshiro.di.unimi.it/ A very fast PRNG, (quite a lot) faster than the fastest current boost generator, with a period of 2 ^ 128, which could/would be good for f.e. game programming (except for shuffling, see below). It also has a state of only 16 bytes on x64. The author states that the distribution is of higher quality than f.e. MT19937-64 <http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-6…>. It's probably best to just read the web-page, as it goes into quite some detail and is in itself the summary of the research conducted in this area. Other than the normal boost complications, it's very easy to implement and I use my simplistic implementation to great satisfaction with the std and boost distributions. In this <https://www.codeproject.com/Tips/1083372/Random-Number-Generator-Recommenda…> article on CodeProject the issue of shuffling is raised. It's appears that shuffling of large arrays of data requires a generator with extremely long periods in order to be able to generate all the possible permutations. To this extent I would like to see in boost a generator like George Marsaglia's SuperKiss <https://groups.google.com/forum/#!topic/comp.lang.fortran/QiTrbq0XeyM> or/and a templated SFMT generator like this <https://sourceforge.net/p/int64/svn/HEAD/tree/snips/sfmt.hpp> one. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 3

[review] Review of PolyCollection starts today (May 3rd)
by Ion Gaztañaga 15 Jun '17

15 Jun '17

Hi everyone, The formal review of Joaquín M. López Muñoz's PolyCollection library starts today. I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements. PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. The library can be found here: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html Please post your comments and review to the boost mailing list (preferably), the Boost Library Incubator. or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Waiting your reviews! Ion

13 51

[review] Review of Nowide (Unicode) continues - summary of the dicussions so far
by Frédéric Bron 15 Jun '17

15 Jun '17

Dear all, The formal review of Artyom Beilis' Nowide library continues until Wed. 21st of June. Here is a summary of the discussions so far: 7 people participate to the review (not counting Artyom and my-self): - Degski - Niall Douglas - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 2 official reviews have been shared, both positive for inclusion in boost (Degski, Peter Dimov). Discussions: Everybody is positive about the usefullness of the library but some major questions arose: 1. how should we handle invalid Unicode sequences (bytes or multi-bytes)? Allow? throws error? 2. there is an unsymmetric way of treatment between Windows and Posix: - on Windows, the conversion from UTF-16 checks for Unicode conformance and returns only valid UTF-8 or fails - on Posix, no check is performed that the input is a valid UTF-8 sequence. 3. in particular, on Windows, the roundtrip conversion UTF-16 -> UTF-8 -> UTF-16 is not guaranted if the initial string is non conformant One main issue is that existing files may have non conformant names and would therefore not been reachable by the nowide API on Windows. On Posix platforms, non conformant paths would work transparently. Different proposals have been made to address this: - convert from UTF-16 to a superset of UTF-8 so that the round-tip conversion is possible, this would mean that the library accepts non conformant strings on Windows as is done on Posix. Question: which enconding should be used (Modified UTF-8, WTF-8, CESU-8)? WTF-8 has the issue of being difficult to handle with string concatenations. - use RtlUTF8ToUnicodeN functions which replace wrong UTF-16 characters by U+FFFD but is this OK for round-trip? - see glib approach - add function to explicitly convert from wide to WTF-8 However, for the Posix case, the issue is that we cannot guarantee that the encoding is always UTF-8 so checking for conformance may be impossible. Hence the choice for not checking on Posix. Minor points: - Missing some documentation on what happens if invalid UTF-8 is provided (getenv, setenv, cout, cerr). - ::setenv on cygwin gives a compile time error (Peter Dimov proposed a fix) - suggestion to add stat and readdir Frédéric

1 0

Packt: Mastering Git - Jakub Narębski
by degski 15 Jun '17

15 Jun '17

To those interested. On Packt, the ebook Mastering Git - Jakub Narębski <https://www.packtpub.com/application-development/mastering-git> is today avaialble for free download, free membership (registration) required. I don't work for Packt. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[poly_collection] Help with Intel 16.0
by Joaquin M López Muñoz 14 Jun '17

14 Jun '17

Hello, Boost.PolyCollection will be released with Boost 1.65 on Aug 9. So far regression tests are looking OK for MSVC>=14.0, GCC>=5.0 and Clang>=3.7: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… For Intel>=16.0, though, all tests pass except test_algorithm (admittedly the one involving more complex code): http://tinyurl.com/ya52o3e5 As I don't have local access to that compiler it is very difficult for me to try to find the needed workarounds. If someone with interest in Intel and access to the tools wants to volunteer to help fix the offending test case, please be my guest. Contact me either through this list or by private email. Thank you, Joaquín M López Muñoz

1 0

Mangled "From" field in mailing list posts
by Vladimir Prus 14 Jun '17

14 Jun '17

Hi, it seems that most of recent posts to the mailing lists have rather strange "From" field, e.g. From: Daniel James via Boost <boost(a)lists.boost.org> I see this problem both via NTTP and regular mail, including emails that appear to be posted directly with a mail client. That extra "via Boost" adds no value, and clutters mailbox. Is there any change to return back to having "From" field have just the name of the person? Thanks in advance, Volodya

7 18

[trac] Add Boost.Process to Boost.Trac component list
by Ion Gaztañaga 13 Jun '17

13 Jun '17

Hi, I recently received a bug report for Boost.Process. Since it is not selectable in the component list the reporter selected "interprocess" which minimizes the error ;-) Could someone with permissions add "process" to the trac component list? Many thanks! Ion

3 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

Boost Build configure checks improvement. [config/predef]
by Rene Rivera 12 Jun '17

12 Jun '17

There's been a long standing "issue" with how the b2 configure checks work. Or rather how some times they don't work. In particular the issue is that the set of properties considered relevant for the configuration checks was fixed. As of last night that is now resolved < https://github.com/boostorg/build/commit/450c25c3b52f5ddcb323140f8423adf3b8… >. As the commit mentions the set is no longer fixed and is configurable by users. The changes now mean that: 1. Any subfeatures of the top level relevant feature set are also considered as part of the set. This means that one can a configuration like below to support multiple invocations of the same toolset with different options. In particular the STD options: === user-config.jam === import feature ; using clang ; feature.subfeature toolset clang : std : cxx03 cxx11 cxx14 cxx17 : optional composite propagated ; feature.compose <toolset-clang:std>cxx03 : <cxxflags>-std=c++03 ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; === And one can then invoke "b2 toolset=clang-cxx14,clang-cxx11" and get non-colliding configuration checks. 2. The set of relevant features is now soft wired as the set of subfeatures of the "<composite>" feature. Which means ones can add to the default set < https://github.com/boostorg/build/blob/develop/src/build/configure.jam#L26>. For example to add threading choice to the relevant features: === user-config.jam === import feature ; import configure ; feature.compose <configure> : <threading> ; === Enjoy. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[outcome] Second high level summary of review feedback accepted so far
by Niall Douglas 11 Jun '17

11 Jun '17

Firstly thanks to everyone who has contributed no less than **618** emails at the time of writing to the Outcome review. Despite some on Reddit calling this review a "train wreck" and indeed some lovely things about me personally, I have found this review deeply helpful, and I believe so have most of its contributors in helping us all firm up our differing opinions about what such a vocabulary type ought to be. With regard to the previous high level summary at http://boost.2283326.n4.nabble.com/outcome-High-level-summary-of-review-fee…, I have made only these changes to the changes in that summary: 1. I have been persuaded to use longer more appropriate naming for result<T> and outcome<T>, so now the typedefed varieties with implicit conversions to their empty-capable form indicated by "=>" are: - static_checked_outcome<T> => static_checked_optional_outcome<T> static_checked_result<T> => static_checked_optional_result<T> These have narrow observers which reinterpret_cast and are therefore undefined behaviour if the state does not match, but use __builtin_unreachable() to help static analysis tooling like clang-tidy spot UB where it can be statically deduced. Conceptually, they are a very thin convenience wrap of std::variant<...>. - runtime_checked_outcome<T> => runtime_checked_optional_outcome<T> runtime_checked_result<T> => runtime_checked_optional_result<T> The runtime_checked_optional_* varieties are identical and unchanged to the outcome<T> and result<T> in the submitted library. They have wide observers with a formal empty state and it is never undefined behaviour to call any observer. This allows the programmer to save typing considerable boilerplate knowing that the runtime checks save the programming needing to spell things out. I have not been persuaded to change a single thing in their design yet apart from removing unnecessary member functions, but thanks to everybody who has tried, and if you think I am making a critical mistake, you still have a few days left to persuade me of it! For anyone not familiar with the discussion and feels that the names are excessively long, be aware they are just convenience typedefs of a more complex to configure "template<...> class outcome_impl". It is expected that end users of the library will choose the varieties they want for their code and typedef them into their local namespace as "result<T>" or whatever. Nobody is proposing that end users actually type out the full name each and every time they use them, and the documentation will make that clear. 2. I have been persuaded to replace the implicit conversion from static_checked_* varieties to runtime_checked_* varieties with explicit conversion instead as the implicit conversion could produce runtime failure where the programmer did not expect that to occur. Regarding other changes that I have accepted since the previous high level summary: 1. Outcome's STL exception throw catch to result<T> super-macro was found to be overkill given that current compilers won't replace simple throw...catch sequences with a branch, and still invoke the full throw-catch runtime machinery whatever the case. Therefore an exception to error code conversion function makes more sense than a macro. https://github.com/ned14/boost.outcome/issues/50 2. Outcome's usage of git submodules is felt by some reviewers to be a showstopper for acceptance as they could bring in non-Boost code unexpectedly in the future. I have agreed to make a cronjob script generated Boost.Outcome from standalone Outcome in the same fashion as Boost.ASIO is script generated from standalone ASIO. https://github.com/ned14/boost.outcome/issues/51 - Licensing to be BSL only - No cmake, just bjam - No git submodules at all - std-flavoured, not boost-flavoured - No code to be brought in except that written by me i.e. a hardcoded whitelist applies. - Contents of Boost repo to only contain material directly relevant to Boost. Nothing else. 3. Under the assumption that error_code_extended's use of a static global ring buffer would be controversial in this review, I hacked a quick and dirty solution expecting to have to remove it. Now we know that few disapprove, a more serious implementation will be needed. https://github.com/ned14/boost.outcome/issues/52 4. Given where Vicente appears to be heading next with expected<T, E1, E2, ...> it may be wise to make the static_checked_* varieties use std::variant<...> for storage when being compiled on C++ 17. https://github.com/ned14/boost.outcome/issues/53 Thanks, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 52