Re: [boost] proposed new library "histogram"

Subject: Re: [boost] proposed new library "histogram"
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2016-05-05 11:39:39

On 5/5/16 11:08 AM, Klemens Morgenstern wrote:

>>> All this sound quite interesting. I took a look at your documentation
>>> and the tests and I have to say: I have no clue what this library
>>> does. That is, yes, it helps you to write histograms, surce, but how
>>> does that look? This might be obvious for you as the developer, but
>>> for me it's completely unclear - maybe you can enhance your examples
>>> by providing the actually generated output.
>>> Because if you want interesent in your library you need people to have
>>> a clue what you're talking about. That does not mean, that you need to
>>> give every detail, but to have an overview and an basic idea would be
>>> nice.
>> May I ask what part of the documentation you looked at? If you had a
>> look at the README.md on the github page only, then I understand what
>> you mean. The README.md does not contain usage examples. I will add some
>> there to improve the appeal of the front page and make the point of the
>> project more clear.
>>
>
> I looked at the html in the repository: 
> https://htmlpreview.github.io/?https://raw.githubusercontent.com/HDembinski/histogram/master/doc/html/tutorial.html
>
> That was the link you provided in the incubator.
>
> Since I only looked shortly into that, the only thing i got, was that 
> you can calculate the variance and over-/underflow in C++. I did not 
> get the python example. You should at least provide the output of the 
> example.
Cool, I was not aware of htmlpreview.github.io, that's useful.

Ok, I will add the output of the examples and more explanation of what 
is actually happening there.
>> Yes, it is pure C++03. I suppose I could replace the internal use of
>> c-arrays with std::array in a few places. Does it matter if they are
>> private members? Shouldn't the internals of a class be a matter of style
>> as long as they work correctly and there is no difference in terms of
>> code readability?
>
> Well, it was declared as C++0x in the incubator, so I wondered. C++03 
> is not a strict requirement for boost (e.g. boost.hana requires C++14) 
> and I personally don't see any benefit in supporting obsolete 
> Standards in new libraries. At least C++11 is widely available today.
> I would really like a class holding data to be movable. And you might 
> probably be able to make good use of constexpr.
I can use Boost.Move to implement that without sacrificing C++0x 
compatibility, so no problem.

Support for C++0x is essential for the target audience of this library, 
among which are big public science projects. All such projects I know 
still work with old compilers and are not likely to adapt the newer ones 
soon. Some big names I can drop are CERN, the IceCube Experiment, Pierre 
Auger Observatory. Big experiments like these rely on support for old 
Linux distributions which are still running on many computing clusters. 
These old Linux distributions do not have modern compilers that support 
C++11.

>
>>
>> About replacing macros with templates: agreed, there are a few places in
>> the interface which could be written in a much nicer way by using
>> variadic templates. I am well aware of the nice C++11 and C++14
>> features, but this was a motivated decision. AFAIK boost libs are
>> required to run on C++0x compilers, so I went for the less elegant, but
>> more compatible option.
>
> Makes sense for C++03.
>
>>
>>>
>>> Also: I think you will still need to provide bjam files, because
>>> that's still the way boost is built (though there has been lively
>>> discussion about cmake).
>> I've been following that, but I didn't notice a conclusion that the use
>> of CMake is prohibited. According to the Boost Incubator, I am allowed
>> to use CMake. I am not eager to write the build again using bjam, but I
>> will do it if that is absolutely required.
>>
>
> The main build of the boost libraries will run on boost.build. Though 
> that's down the road, and I'll gladly help you when that becomes 
> necessary. Though you might think about adding travis-ci and coveralls 
> to your repository.
Thank you for your offer to help with bjam, I really appreciate it. I 
also think it is something that can be done later.

I will look into adding support for travis-ci and coveralls.io.

I already added all these suggestions to the issue tracker on github.

Best regards,
Hans