C++ Logo

std-proposals

Advanced search

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

From: Paul Caprioli <paul_at_[hidden]>
Date: Thu, 28 Aug 2025 20:28:38 +0000
> I rather think std::float64_t should really be a typedef to a standard floating point type (typically double) when and only when that type is an IEC60559 Binary64. Is that realistically a possibility, or the ship has sailed? > 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. Suppose, as a library developer, I want to provide both APIs. I've already implemented void daxpy(std::size_t, std::float64_t, const std::float64_t*, std::float64_t*); I'd like to provide a header-only implementation of void daxpy(std::size_t, double, const double*, double*); that calls the previous function. The pointers are passed by value. I'm expected to modify the floating-point values pointed to by the last parameter. Raw pointers are non-owning. I would never use delete on a raw pointer given to me as an argument. For the same reason, it seems not OK to std::start_lifetime_as_array<std::float64_t>(ptr) on a raw pointer given to me as an argument.

Received on 2025-08-28 20:28:41