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-19 08:39:13

> On 19. Sep 2018, at 01:17, Gavin Lambert via Boost <boost_at_[hidden]> wrote:
> 
> One trivial case is where the input is integers (or an arbitrary-precision bigint type of some sort) but for whatever reason you want to get a histogram of the log or square root or something else floating-point.

Ok, good point. I have another practical use case. I think axis::regular should work with Boost.Units, so you can make an axis that accepts only energies. The transform in this case would strip off the unit to produce a dimensionless scale which is then binned.

https://github.com/HDembinski/histogram/issues/92

> Another case might be where you want to use a larger structure as your input and use the transform to extract one particular field.  Although this is probably less useful since it's a lossy transform and the inverse wouldn't be able to produce the full original object -- unless perhaps the transform was stateful and preserved its input (which doesn't make much sense as presumably it's non-unique, otherwise you wouldn't be using a histogram), or you don't care about the other fields in the structure when producing the inverse, or you don't need to make any calls which require calculating the inverse.
> 
>> AFAIK, the order in which these statements are executed is not guaranteed,
>> that's why the ctor uses trans instead of transform_type. I am happy to be
>> proven wrong by a language expert. If that's the case, I agree that your
>> suggestion makes more sense.
> 
> It would require a special kind of crazy for a compiler to emit calls to an instance method of a base class before calling the base class constructor.  So I'm reasonably positive that it's safe.
> 
> Steven's already addressed this as well, which seems to agree.  Although I must admit a little surprise; I thought I remembered that even though the actual initialisation of members occurs in the defined order, evaluation of arguments to the initialisers might not be.  Perhaps this was something tightened in C++11?

I think my mistake was the following. When you call a function or a constructor, the order in which the arguments are evaluated is not guaranteed by the standard. But this here is a different case.