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

Subject: Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2018-09-26 08:57:05

Hi degski,

> On 26. Sep 2018, at 07:40, degski via Boost <boost_at_[hidden]> wrote:
> 
> On Tue, 25 Sep 2018 at 22:53, Hans Dembinski via Boost <
> boost_at_[hidden]> 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