- Boost - lists.preview.boost.org

[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

Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
by Bjorn Reese 31 Dec '17

31 Dec '17

On 12/31/17 01:28, Peter Dimov via Boost wrote: > What (non-cryptographic) hash functions should a hypothetical future > Boost hash library contain? Have clear winners emerged by now? Which > ones do people prefer? I vote for FNV hashes: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

1 0

What hash functions should be included in a hypothetical Boost hash-v2 library?
by Peter Dimov 31 Dec '17

31 Dec '17

What (non-cryptographic) hash functions should a hypothetical future Boost hash library contain? Have clear winners emerged by now? Which ones do people prefer? SipHash is basically a given, but it's not optimized for speed.

5 6

Removing hash from Boost.Functional broke modules
by James E. King, III 28 Dec '17

28 Dec '17

See: https://github.com/boostorg/type_index/issues/18 There is no forwarding header to keep things compatible. - Jim

2 1

Maintenance of Boost.DateTime
by James E. King, III 28 Dec '17

28 Dec '17

The backlog for Boost.DateTime in trac has over 130 issues; the project is holding on to very old backwards compatibility code (pre-boost-1.33.0 i/o facets), and the CI builds do not currently have appveyor, codecov.io, or coverity scan integration. It needs a proper maintainer in order to resolve these issues, so I would like to ask for that privilege. Thanks, Jim

1 0

Appveyor and Travis CI notifications of Boost library tests
by Edward Diener 26 Dec '17

26 Dec '17

Is there a way to tell Appveyor or Travis CI to send notifications of its Build runs of Boost libraries to someone other than myself ?

4 7

Candidate for 1.66.1, if there is one
by James E. King, III 25 Dec '17

25 Dec '17

In Boost 1.66.0, there was a fix to date_time for the year 2038 problem: https://github.com/boostorg/date_time/pull/35 The serialization code in date_time had no static assertions enforcing the size of data values, and adding proper versioning support was missed in the release by myself and not picked up in the code reviews. As a result, serializing in anything written by earlier boost versions fails for date_time related structures, which might be considered serious enough to justify a 1.66.1 release. (We could also get the latest msvc compatibility in there I suppose...) I'm adding proper versioning right now, however Boost 1.66.0 will remain a problem since it serializes in/out as Version 0 with 64-bit values; and 1.65.1 serializes in/out Version 0 with 32-bit values so I'm not certain there will be a way to detect this issue. The issue is recorded in github here: https://github.com/boostorg/date_time/issues/56 Any additional thoughts are appreciated. I'm looking at adding a test to write out a version 0 and then read it in when the current version is 1, but I don't want to add test-only support code to the headers that get shipped, so if anyone can point me at a current example unit test that writes out a "n-1" version and then reads in a "n" version with boost::serialization I would appreciate it. Thanks, Jim

9 22

Getting Started
by ishan garg 25 Dec '17

25 Dec '17

Hello everyone, I am new to OpenSource Development. I know basics of C++ and acquainted with it's STL. I have basic knowledge of DSA as well as few git commands (clone, push, commit, etc). I wanted to know how can I start contributing to BOOST library? Thanks in Advance -- Regards, Ishan Garg

2 1

library maintainer list
by Robert Ramey 24 Dec '17

24 Dec '17

I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now. Robert Ramey

6 10

regarding mailing list traffic
by Mudit Sharma 22 Dec '17

22 Dec '17

Dear All, I have recently not been receiving the daily Boost mailing list digest, is there some maintenance work going on ? Thanks! M

2 1

[date_time] Trac 13194 - %e posix time_input_facet specifier behavior
by James E. King, III 21 Dec '17

21 Dec '17

https://svn.boost.org/trac10/ticket/13194 Just looking at this one, and looking at the documentation, it states that %e is the same as %d however when the value is less than 10, a leading space is to be used instead of a leading zero. The example in the description has a flaw, I believe, and I commented on that. Do folks agree with my comment? Should parsing fail if it says "December 5" (with one space) and the format string is "%B %e"? Valid input would be "December 5" (with two spaces). I also found that the code blindly ignores delimiter specifiers, so I opened a github issue for it: https://github.com/boostorg/date_time/issues/53. Comments appreciated there as well. Thanks, Jim

2 2