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

Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-06 05:06:44

On Wed, Nov 6, 2013 at 1:53 PM, Paul A. Bristow <pbristow_at_[hidden]> wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
>> Sent: Wednesday, November 06, 2013 9:08 AM
>> To: boost_at_[hidden]
>> Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
>> >
>> >> How about:
>> >> cpp_bin_float_single;
>> >> cpp_bin_float_double;
>> >> cpp_bin_float_quad;
>> >
>> > Fine with me! Those are good names --- consistent with existing Boost
>> > style, easy to recognize, and unambiguous.
>> > Can we get a consensus on those names?
>>
>> One other suggestion:
>>
>> cpp_float32_t
>> cpp_float64_t
>> cpp_float128_t
>>
>> which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix
> indicates it's
>> a software emulation?
>
> I think I like these a bit better - except that should they be
>
>   cpp_bin_float32_t
>   cpp_bin_float64_t
>   cpp_bin_float128_t
>
> I know it's more to type, but it's important that they are recognised as a binary type?

I'm not a user of Boost.Multiprecision, but maybe namespaces would do
a better job in distinguishing the types? Injecting various tags into
the type names feels like C-style.

Or maybe a trait to construct the necessary type:

template< unsigned int Bits >
struct floating_point
{
    typedef ... hardware_type; // optional
    typedef ... emulated_type;
    typedef ... type; // hw, if available, emulated otherwise
};

typedef floating_point< 32 >::type my_float32_t;

Just some thoughts...