Date: Thu, 29 May 2025 20:40:26 -0300
On Thursday, 29 May 2025 18:36:45 Brasilia Standard Time Jan Schultke via Std-
Proposals wrote:
> Hi,
>
> I'm working on a proposal that would add functions for integer
> division in various rounding modes:
>
> https://isocpp.org/files/papers/D3724R0.htm
>
> This is something I actually wanted to write years ago, but I was
> under the false impression that SG6 is already working on this
> problem. In reality, the proposal P0105R1 which last worked on this
> was abandoned a long time ago.
>
> Anyway, please share your thoughts :)
You're proposing an interface with templates. Are you sure they can be
implemented efficiently inline for all architectures? Shouldn't they be out-of-
line and provide only int, long, and long long support via overloads?
Paralleling the std::div function, should this return div_t? On some
architectures, the division instruction already provides the modulus, so it
would be useful to return both at the same time. In your reference
implementation, every single std::div implementation is calculating both (x/y)
and (x%y), so it probably won't be too expensive to just return both quotient
and remainder anyway. In any case, given the precedent API that std::div
poses, it's probably better to follow it for anything whose name starts with
std::div and find another name for quotient-only results.
I'd also suggest this be proposed to the C standard. There's nothing here that
requires C++ or benefits only C++. C2y may get constexpr functions and, even if
they don't, it would be easy for implementations to provide the std:: versions
with constexpr with a suitable if consteval.
Finally, why so many options? Do we really need them? Why can't we settle for
the standard ones from the FP environment: nearest (odd/even tie breaking),
towards +Inf, towards -Inf, and towards zero?
Proposals wrote:
> Hi,
>
> I'm working on a proposal that would add functions for integer
> division in various rounding modes:
>
> https://isocpp.org/files/papers/D3724R0.htm
>
> This is something I actually wanted to write years ago, but I was
> under the false impression that SG6 is already working on this
> problem. In reality, the proposal P0105R1 which last worked on this
> was abandoned a long time ago.
>
> Anyway, please share your thoughts :)
You're proposing an interface with templates. Are you sure they can be
implemented efficiently inline for all architectures? Shouldn't they be out-of-
line and provide only int, long, and long long support via overloads?
Paralleling the std::div function, should this return div_t? On some
architectures, the division instruction already provides the modulus, so it
would be useful to return both at the same time. In your reference
implementation, every single std::div implementation is calculating both (x/y)
and (x%y), so it probably won't be too expensive to just return both quotient
and remainder anyway. In any case, given the precedent API that std::div
poses, it's probably better to follow it for anything whose name starts with
std::div and find another name for quotient-only results.
I'd also suggest this be proposed to the C standard. There's nothing here that
requires C++ or benefits only C++. C2y may get constexpr functions and, even if
they don't, it would be easy for implementations to provide the std:: versions
with constexpr with a suitable if consteval.
Finally, why so many options? Do we really need them? Why can't we settle for
the standard ones from the FP environment: nearest (odd/even tie breaking),
towards +Inf, towards -Inf, and towards zero?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-05-29 23:40:36