Boost logo

Boost :

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk