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?