January 2018 - Boost - lists.preview.boost.org

[contract] ready to release
by Lorenzo Caminiti 10 Jan '18

10 Jan '18

Hello release managers & all, Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.). What do I have to do to put https://github.com/boostorg/contract.git master into Boost release 1.67? Thank you. --Lorenzo

2 3

Potential Boost SAX library
by Oliver Adams 10 Jan '18

10 Jan '18

Hi all, I was wondering if a library I'm developing would be of value to the Boost community. It is basically an event-driven parsing/serialization library for common formats using a standard internal representation or simple pass-through conversions. Would anyone be interested in something like this being added to Boost? Thanks.

4 6

[outcome] Training video in post-Toronto std::expected<T, E>
by Niall Douglas 09 Jan '18

09 Jan '18

In preparation for the Outcome v2 review next week, reviewers may find the video of my Meeting C++ talk in Berlin last year useful to watch beforehand. The talk is a literature review covering all the WG21 papers related to the post-Toronto std::expected<T, E>, which is quite different to the Expected during the Outcome v1 review. https://www.youtube.com/watch?v=JfMBLx7qE0I My thanks to Jens for prioritising the release of this video, and for running a great C++ conference. I'm still building a list of errata for the video, once complete I'll post a list underneath it. Any mistakes that I made, please do let me know, ideally with a timestamp offset into the video. My thanks to all those who are currently reporting so many, many bugs in the reference docs. I'll try my best to fix them all before end of next week, but keep them coming! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Re: [boost] seeking endorsement for histogram library
by Bjorn Reese 09 Jan '18

09 Jan '18

I endorse boost.histogram.

6 11

[date_time] recommending upgrading the timezone database
by James E. King, III 07 Jan '18

07 Jan '18

The timezone database in Boost.DateTime doesn't have enough information in it to be accurate all the time. For example if a region changes time zone rules, when applying timezone only the current rule will be applied regardless of the date involved. If a region stops using daylight savings time, but a date/time falls before that rule change, it should still use daylight savings in printed output, correct? The IANA timezone database is more complete, and we could switch Boost.DateTime to use that instead. It is also maintained more frequently than the built-in one, which was last updated 7 years ago, and 4 years before that. Any thoughts on this? https://github.com/boostorg/date_time/issues/67 - Jim

2 1

Adding AppVeyor as a required check to a Boost repository on Github
by Edward Diener 07 Jan '18

07 Jan '18

I am trying to add AppVeyor as a required check to the boostorg/date_time repository on Github. I have gone through the step of adding 'develop' as a protected branch, checking "Require status checks to pass before merging", and checking "Require branches to be up to date before merging". The only thing that then appears in the settings for the protected 'develop' branch is: "Status checks found in the last week for this repository" is "continuous-integration/travis-ci" "required", which is checked. Nothing about AppVeyor whatsoever. Anyone know what the Github voodoo is for getting this to happen ? I see other Boost repository with both Travis-CI and Appveyor required checks but evidently the doc for doing this for AppVeyor is non-existent in Github.

1 0

[hash] Extract module from functional + std::hash_combine
by Daniel James 06 Jan '18

06 Jan '18

Hi, I'm planning to extract hash from functional into its own module, as that will apparently break the circular dependencies that functional is part of. Any objections? Also, any opinions on what the module should be called? 'hash' might suggest a more general purpose hash function, so maybe it should be called something more specific. Daniel

10 29

[date_time] Eliminate pre-1.33.0 io facet code?
by James E. King, III 06 Jan '18

06 Jan '18

There was a bug change around the 1.33.0 release timeframe that added new io facet handling for date_time. It is conditionally disabled using the definition USE_DATE_TIME_PRE_1_33_FACET_IO. I suggested in a github issue that the pre-1.33 mode be removed at this point. Any thoughts on that? https://github.com/boostorg/date_time/issues/61 - Jim

2 1

[outcome v2] Pre-review feedback
by Niall Douglas 05 Jan '18

05 Jan '18

Outcome v2's review starts on Friday 19th January, after which I can't fix even obvious problems. The documentation is by far the newest and most experimental part using bleeding edge tooling, so getting a few rounds of fixes in now before locking everything down for the review would be great. Can those who are super keen have a look at the reference API docs and find problems that me and Jonathan can fix before the review begins? You can find the reference API docs at: https://ned14.github.io/outcome/reference/ And issues can be logged to https://github.com/ned14/outcome/issues or https://github.com/foonathan/standardese/issues if you're sure of the source of the problem. Potential problems to look out for (not a complete list): - Lack of documentation summary string - Confusing or meaningless documentation - Incomplete or mangled documentation for some entity (e.g. sentences missing sections, lines reordered) - Leakage of "detail" namespace or of types or macros clearly of internal implementation detail - Stray or missing commas, angle brackets, brackets - Missing or insufficient requirements, effects or throws clauses - Appearance of any `std::enable_if`, these are supposed to be suppressed into requirements, but I know `outcome.hpp` is particularly bad on that (tracked by https://github.com/ned14/outcome/issues/76) - Lack of hyperlinking to other parts of the reference docs where that was clearly intended. To expand on the "bleeding edge tooling" part, these reference API docs are generated using https://github.com/foonathan/standardese which is based on clang libtooling. Some of the problems are caused by clang libtooling, some by standardese, some by me. I don't doubt that these reference API docs are an enormous improvement over those from doxygen - especially the ability to search semantically for stuff related to search term - but there are a lot of very small problems I'd love to clean up before the formal review begins. Thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Changing the website (Was: Need help with bootstrap.bat)
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

2018-01-03 13:54 GMT+01:00 Daniel James via Boost <boost(a)lists.boost.org>: > On 3 January 2018 at 10:04, Andrzej Krzemienski via Boost > <boost(a)lists.boost.org> wrote: > > > (n.b. It was very difficult to find this page as there is no direct link > > from www.boost.org) > > I'll add a link to the 'getting started' section. Maybe we should move > more content onto the github wiki? It's just a git repo with markdown > pages so it shouldn't be too hard to serve it from the website if > people would like it to be more integrated. > Let me share with you my recent experience. I was looking for something like "getting started for Boost developers" and could not find a place.In the front page there is section "INTRODUCTION", but it looks like content for potential users (rather than developers). There is section "DEVELOPMENT" but the content is more like "how to submit a new library", but no "getting started with developement" (on somebody else's library) There is a "WELCOME" -> "Getting started", but it looks like one for the users. (it recommends downloading a zip file). There is this non-obvious path: DEVELOPEMENT -> Reporting and Fixing Bugs. While there, click on "git repositories". It opens a stub page that says it has been superseded by another, and when you push on a link you get there. But this really should be simpler. Maybe in the front page we should have "DEVELOPMENT" -> "Getting Started" that links directly to https://github.com/boostorg/boost/wiki/Getting-Started Or maybe the topics should be divided differently: - Getting started with using Boost Libraries - Getting started with applying improvements to existing Libraries - Getting started with submitting a new library. I consider this more important than where actually the content is hosted. Regards, &rzej;

7 13

[test] Test cases parametrized by both type and value?
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

Hi, Can anyone tell me if Boost.Test can solve the problem that I describe below. I have a function template inspect: ``` template <typename T> bool inspect(T const& v); ``` I want to test if it returns `true` for the following values: 1 (type int) 10 (type int) 1.0 (type double) "Y" (type const char *) Basically, different values of different types, but sometimes different values have the same type. I would like to write one test or "test template" with the following contents: ``` BOOST_TEST((inspect(v))); ``` Where `v` is name of the currently tested value. (But `v`s will have different types). I can emulate this behavior using template test cases and artificial types: ``` struct int_1 { static int value() { return 1; } }; struct int_10 { static int value() { return 10; } }; struct double_1 { static double value() { return 1.0; } }; struct cstr_Y { static const char * value() { return "Y"; } }; typedef boost::mpl::list<int_1, int_10, double_1, cstr_Y> test_types; BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types ) { BOOST_TEST(inspect(T::value())); } ``` (See working example in WandBox: https://wandbox.org/permlink/KcJqT8KvL3zIqAxL) But maybe there exists a direct solution in Boost.Test? Where I would just pass a list of values: `{1, 10, 1.0, "Y"}` It is easy to deduce types from values: ``` template <typename... T> mpl::liss<T...> Values(T... values); using test_types = decltype(Values(1, 10, 1.0, "Y")); ``` Does something like this exist, or ois it a reasonable extension? Regards, &rzej;

4 3

[regression] results pages not updating
by Joaquin M López Muñoz 04 Jan '18

04 Jan '18

Hi, Just a heads up, regression tests result pages: http://www.boost.org/development/tests/master/developer/summary.html http://www.boost.org/development/tests/develop/developer/summary.html aren't updating since Jan 1. Thank you, Joaquín M López Muñoz

3 5

Interest for a Fixed Point Arithmetics library
by Julien Vernay 03 Jan '18

03 Jan '18

Hello everybody. I am working on a project that needs and can use fixed point numbers, so I started searching for a library implementing fixed point numbers, but I didn't find anything. So I was wondering if people would need fixed point arithmetics, and here I am. The aim of this FixedPointNumber is to fix the point at compile-time using template, and having another template argument for the underlying type. So we have : template<typename T, size_t N> class FixedPointNumber { T value; public: //interface }; The N last bits of value is the decimal part : so to convert a FixedPointNumber to an int, we need only to use a bitshift operator (and same for construction from int). sizeof(FixedPointNumber<T,N>) == sizeof(T) , so there is no overhead in this implementation. Arithmetic and relational operators will be implemented. Multiplication needs one int multiplication and one bit shift. Division needs one int division and one bit shift. There is only one value for zero. Sign can be extracted with Most Significant Bit. I have already a basic implementation but if it interests more people I will do a proper implementation. Thank you for reading !

4 7

[multiprecision] Help needed with strange constexpr slowdown
by John Maddock 03 Jan '18

03 Jan '18

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 3

Need help with bootstrap.bat
by Andrzej Krzemienski 03 Jan '18

03 Jan '18

Hi Everyone, Maybe someone can help me with configuring bootstrap.bat. I am trying to set up the environment for developing boost libraries, and it is my understanding that the first step (after cloning a git repository) is to build b2 itself using the script bootstrap.bat. I got this from instructions at https://github.com/boostorg/boost/wiki/Getting-Started (n.b. It was very difficult to find this page as there is no direct link from www.boost.org) I am using MinGW on Windows, no Visual Studio installed. Nonetheless bootstrap.bat concludes that it should compile with cl.exe, and it does not work. I know that MinGWis not supported, but I have to take my chances. Maybe somebody knows how to instruct bootstrap.bat to select a GCC compiler and tools? Regards, &rzej;

5 6

help for contribution
by ashwin.pathak 03 Jan '18

03 Jan '18

Hi Developers, I am very interested in computer programming and I find boost c++ libraries really exciting. I would like to contribute to the organization, I am new to this organization. Can someone please help me to get started in contributing to the organization. Thank you, Best Regards, Ashwin Pathak

1 0

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17