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
> 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
Ok, fair point.
> 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]]
> 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! :)