Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY

Hi degski,

On 26. Sep 2018, at 07:40, degski via Boost wrote:

On Tue, 25 Sep 2018 at 22:53, Hans Dembinski via Boost < boost@lists.boost.org> wrote:

As this issue caught my attention, I decided to read the readme.md. I think you should remove the word modern in "modern C++11 design". I don't doubt you designed it well, but 1. C++11 is not modern and 2. today's modern is tomorrow's old (Boost.Histogram might not even make in into 1.69, which will push it to 2019), just stick with "C++11 design", that's precise and clear.

Ok, fair point. https://github.com/HDembinski/histogram/issues/108

But, elaborating the above, are there any benefits [low hanging fruit] to be had from C++14 and/or C++17. One I can think of, which would have caught the example problem (at compile time), is the use of the [[nodiscard]] attribute. As you can see, live here, it's a biggie. Then there are static_assert's, extended constexpr (more compile time stuff), noexcept and direct-list-initialization. Structured bindings is maybe something as well [the buckets]. If you strive to make it "modern" (but please don't talk about it), you should actually make it modern and conditionally add C++17 features.

I considered requiring a more recent C++ standard. Generic lambdas and automatic return type deduction would have made the internal code simpler. Template deduction of constructors would have been useful. std::string_view could have replaced boost::string_view and std::variant boost::variant. In the end I concluded that while it would have made my life as the implementer a little easier, the cost of dropping support for older compilers outweighs these benefits. C++17 features on the user-facing side will be added conditionally over time, of course. I added an issue for [[nodiscard]] https://github.com/HDembinski/histogram/issues/107

Just one last thing, it is (really) good that this example issue was caught by that/the poster as beginners/first-time-users will be stumped by this kind of thing and will do a RYO instead.

Absolutely, this is bad. I am testing that all examples in the docs compile, but I should also test the output. Which some hackery I can probably also automatically test the code in the README.md. Apparently is no include-code-from-file statement for Markdown.

No review, but I vote to include!

Cool, thanks! :) Best regards, Hans