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

Subject: Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-09-18 23:17:10

On 19/09/2018 06:55, Hans Dembinski wrote:
> True, there is an inherent assumption that the transform does not change
> the value_type and only do a monotonic mapping, like log(x) or pow(x,
> const). But like you point out, this restriction is not necessary and it is
> easy to avoid. But just out of curiosity, can you name a use case where the
> transformed type is different from the value type?

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.

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?