Re: [boost] [multiprecision] Radix-2 typedef naming convention

Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-03 23:21:30

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.