Date: Thu, 3 Apr 2025 10:15:25 +0000
I'm not sure I understand your proposal.
Except for div_wide, all of the proposed functions are well defined, I.e. no matter what arguments you pass there's a definite well-defined answer that the function is expected to return.
The only exception is div_wide, which has a domain of input values that are considered invalid and intentionally left undefined.
Even tough x86 is a popular CPU architecture, that does have a dedicated division instruction, most "other" CPUs don't, so in most "other" cases it is going to be implemented as a function proper rather than a CPU instruction.
x86 doesn't throw exceptions, what happens in this case if inputs are outside of the valid domain the CPU traps. Have tested this with major compiler vendors (MSVC, gcc), which although you can catch this with a blank catch clause (...) it doesn't have a type, it's not a real C++ exception, it doesn't work very well with the C++ exception model.
I've explored the avenue of using exceptions and allowing for a wider range of usage scenarios, and although you can change the implementation to accommodate throwing C++ exceptions, its is not without consequences.
First in order to accommodate exceptions you would need to fatten the functions in order to make the checks before entering the invalid domains where the CPU or the code could break down.
* The target algorithms where this has been designed around can never be in an invalid domain, so paying that cost is excessively high compared to what it should have been. i.e. 0.
* The objective of the function is to be as low level as possible (single instruction for CPUs that have them, the thinnest possible function for those that don't), adding that extra layer might make this unattainable.
* If being in an invalid domain is a possibility, a function has been provided (is_div_wide_defined) to check for those, the cost of which is expected to be about the same as it would cost you to implement the check inside div_wide itself (minus the exceptions). You can opt in to that cost. Allowing you to create your own "exception enabled" dive_wide alternative if you really need it for your use case.
* Experienced developers already naturally check for "invalid domain" (such as for example checking division by 0) even when unnecessary, so making it uniform would help.
* Other equivalent operations such as 1/0 or std::div_sat(x, 0); (also coming in C++23) also don't throw exceptions and expect you to do the domain validation yourself, making the standard inconsistent in expected behavior were this any different.
The problem with defining in the standard that div_wide shall throw a specific exception when outside a valid domain, is that all implementations would have to follow that rule in order to be conformant. And it would be more advantageous to leave it explicitly undefined, such that on different platforms a library implementer can use any trick available to make it the most efficient as it can be (as long as the result in the valid domain is the same) even if that means inconsistent behavior in the undefined portion.
Part of this is explained in the updated version of the paper: https://isocpp.org/files/papers/P3161R4.html
It was considered at some point, I wanted to add it, but the number of overwhelming factors dictated that this was the best way to do it.
They are simply too low-level, there's no room to fit anything else.
-----Original Message-----
From: Hans Åberg <haberg_1_at_icloud.com>
Sent: Thursday, April 3, 2025 10:48 AM
To: std-proposals_at_[hidden]
Cc: Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Integer overflow arithmetic with exceptions
Might it be possible to extend the proposal “Integer overflow arithmetic” (below), enabling throwing exceptions for overflows in the case the CPU supports it? The purpose is to enable constructing a type with performance in the absence of overflow approaching that of the built-in integral types, switching to higher precision when there is, and it is not possible to get high performance by conditional checks within the C++ language.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3161r2.html
https://lists.isocpp.org/std-proposals/2024/02/9079.php
Except for div_wide, all of the proposed functions are well defined, I.e. no matter what arguments you pass there's a definite well-defined answer that the function is expected to return.
The only exception is div_wide, which has a domain of input values that are considered invalid and intentionally left undefined.
Even tough x86 is a popular CPU architecture, that does have a dedicated division instruction, most "other" CPUs don't, so in most "other" cases it is going to be implemented as a function proper rather than a CPU instruction.
x86 doesn't throw exceptions, what happens in this case if inputs are outside of the valid domain the CPU traps. Have tested this with major compiler vendors (MSVC, gcc), which although you can catch this with a blank catch clause (...) it doesn't have a type, it's not a real C++ exception, it doesn't work very well with the C++ exception model.
I've explored the avenue of using exceptions and allowing for a wider range of usage scenarios, and although you can change the implementation to accommodate throwing C++ exceptions, its is not without consequences.
First in order to accommodate exceptions you would need to fatten the functions in order to make the checks before entering the invalid domains where the CPU or the code could break down.
* The target algorithms where this has been designed around can never be in an invalid domain, so paying that cost is excessively high compared to what it should have been. i.e. 0.
* The objective of the function is to be as low level as possible (single instruction for CPUs that have them, the thinnest possible function for those that don't), adding that extra layer might make this unattainable.
* If being in an invalid domain is a possibility, a function has been provided (is_div_wide_defined) to check for those, the cost of which is expected to be about the same as it would cost you to implement the check inside div_wide itself (minus the exceptions). You can opt in to that cost. Allowing you to create your own "exception enabled" dive_wide alternative if you really need it for your use case.
* Experienced developers already naturally check for "invalid domain" (such as for example checking division by 0) even when unnecessary, so making it uniform would help.
* Other equivalent operations such as 1/0 or std::div_sat(x, 0); (also coming in C++23) also don't throw exceptions and expect you to do the domain validation yourself, making the standard inconsistent in expected behavior were this any different.
The problem with defining in the standard that div_wide shall throw a specific exception when outside a valid domain, is that all implementations would have to follow that rule in order to be conformant. And it would be more advantageous to leave it explicitly undefined, such that on different platforms a library implementer can use any trick available to make it the most efficient as it can be (as long as the result in the valid domain is the same) even if that means inconsistent behavior in the undefined portion.
Part of this is explained in the updated version of the paper: https://isocpp.org/files/papers/P3161R4.html
It was considered at some point, I wanted to add it, but the number of overwhelming factors dictated that this was the best way to do it.
They are simply too low-level, there's no room to fit anything else.
-----Original Message-----
From: Hans Åberg <haberg_1_at_icloud.com>
Sent: Thursday, April 3, 2025 10:48 AM
To: std-proposals_at_[hidden]
Cc: Tiago Freire <tmiguelf_at_hotmail.com>
Subject: Integer overflow arithmetic with exceptions
Might it be possible to extend the proposal “Integer overflow arithmetic” (below), enabling throwing exceptions for overflows in the case the CPU supports it? The purpose is to enable constructing a type with performance in the absence of overflow approaching that of the built-in integral types, switching to higher precision when there is, and it is not possible to get high performance by conditional checks within the C++ language.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3161r2.html
https://lists.isocpp.org/std-proposals/2024/02/9079.php
Received on 2025-04-03 10:15:28