On 2/11/2013 05:23, Quoth Christopher Kormanyos:
I think float32_t, float64_t, float128_t are better since they describe the size of the type and are aligned with integer typedefs.
That was my thought, although note that in the case of the Boost.Multiprecision types these are emulations of those hardware types and are not actually 32, 64 or 128 bits in size. And evn in hardware, an 80-bit extended real may actually occupy 128 bits in memory...
Ahhh... I see your point, John. The multiprecision types are not intended to be IEEE754 conformant. And our own proposal for typedefs having specified widths reserves such names for IEEE754 conformant types.
I'm just a bystander (who probably won't be using the library, so take this with a grain of salt), but I'm leaning towards thinking it better to reserve those names (float32_t etc) for actually IEEE754 compliant types, eg. some future <cstdint> or similar defining "typedef float float32_t" etc. (It wouldn't surprise me if some existing applications already do something similar.) Given that Boost has stdint emulation this would also reserve boost::float32_t etc. You might be able to use boost::multiprecision::float32_t etc but I think this might be too confusing, especially for the people who are in the habit of "using namespace". So something unique might be better. I don't know whether that should be "mp_float32_t" or "float_single_t" or "float24p_t" or some other combination.