As an illustration, I configured three examples from documentation, so that they are only compiled when support for variadic macros is present on the compiler. I am using a feature from Boost.Config: http://www.boost.org/doc/libs/1_58_0/libs/config/doc/html/boost_config/build_config.html
It uses predefined platform macros (rather than tester name) to detect the availability of the feature.
With this change we get a *desired* compile time failure when we are passed type `T` that is not implicitly convertible from `int` but is explicitly convertible. Now, we make an implicit conversion from `int` a requirement and refuse to compile otherwise.
This addresses an issue where the user gives us a type `T` with non-intuitive construction from `int`.
Prior to this change, in floating-point computations, in the case
where we work for types where std::numeric_limits are not specialized,
funcitons min() and max() from std::numeric_limits<FPT> are nonetheless
instantiated and return FPT(0). While the result is never used in run-time,
this may still trigger a compile-time failure.
After this change, the paths for the cases where std::numeric_limits are not
specialized are handled by separate specializations rather than run-time if
statements.
Rationale:
Because we are not using the literal of type double, we avoid the bug where `FTP(0.01)` is evaluated as `FTP(int(0.01))` for FPT types that do not offer a conversion from `double`.
I do not use an explicit cast `v / FPT(100)` in order to allow the compiler to see that we are dividing by the integer, and engage optimizations for that case, if any.
By `v / 100` I require that conversion from int to FPT is implicit, and thereby avoid executing explicit constructors, which may have non-conversion semantics.
To the best of my knowledge, `v / 100` is not less accurate than `v * 0.01`. It may be slower, but given that this is evaluated in BOOST_TEST, which does lots of ops on IO streams, this should be negligible; plus, we are affecting only a percentage tolerance manipulator -- not the floating-point comparison itself.
