C++ Logo

std-proposals

Advanced search

Re: [std-proposals] TBAA and extended floating-point types

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Thu, 28 Aug 2025 06:12:50 +0000
Or you just template it. Or not support double.
There are many options.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Thursday, August 28, 2025 05:33
To: std-proposals_at_[hidden]g
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] TBAA and extended floating-point types

On Wednesday, 27 August 2025 18:50:54 Pacific Daylight Time Julien Villemure- Fréchette via Std-Proposals wrote:
> The argument in P1467R9 that the get_exponent function below is moot
> on a
> IEC559 platform. int get_exponent(double x) { /* ... */ }
> int get_exponent(std::float64_t x) { /* ... */ }
>
> If both double and std::float64_t have identical representation,
> behavior and intent, then I expect both overloads of get_exponent will
> have identical function body implementation with indistinguishable
> behavior for every pair of equivalent double/std::float64_t inputs.
> This situation makes overloading both useless, and a burden: implement
> identical code with identical behavior for types with identical
> behavior and identical representation. Not to mention all possible
> function signatures using double would often also need to be deduplicated.

Indeed but you can turn the argument around: suppose I am writing some mostly- generic content and I don't *know* whether double and float64_t are the same or not. If one is a typedef for the other, I can't create overloads, meaning I have to #if my code on something.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering

Received on 2025-08-28 06:12:53