You actually misunderstood my intention, I emphasized that:
1. To avoid UB with zero divisors, programmers must explicitly check if the divisor is zero, introducing conditional branches. In scenarios where the divisor is almost always non-zero, this leads to branch prediction failures, which may disrupt the pipeline in CPU and degrade the performance significantly.
(Though "an exception will cost more", but in most case, the divisor is not 0, and it will not use any JMP instruction, so it will faster. Using exception is a very common way to avoid branch and optimize.)
2. Languages like Java and Python throw exceptions when dividing by zero, allowing developers to handle such cases elegantly through exception handling mechanisms rather than relying on UB.
These are significantly advantages, aren't they?
________________________________
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Wednesday, April 30, 2025 9:14 PM
To: std-proposals_at_[hidden]ocpp.org <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>; None <a1343922569_at_[hidden]>
Subject: Re: [std-proposals] Proposal: Integer division/remainder/division-remainder functions with exception throwing behavior

Even if checking for zero wasn't the most efficient way to implement it, a compiler is allowed to transform

> if (divisor == 0) [[unlikely]] throw ...

into something more optimal. Maybe there is a way to handle the hardware trap on division and recover from that with an exception throw. The cost of a division is also relatively large, and I doubt that the zero-check has much performance impact.

Anyhow, any proposal will obviously need some feedback from implementers, performance measurements, etc. Until proven otherwise, checking for zero is a perfectly valid solution already, and adding such a "div_with_exception" function would be a waste of committee time.