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

On 19. Sep 2018, at 01:17, Gavin Lambert via Boost 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.