- Boost - lists.preview.boost.org

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