我用c++写了一个程序来寻找ab = C的所有解，其中a, b和C一起使用所有的数字0-9，只使用一次。程序循环遍历a和b的值，并每次对a、b和ab运行数字计数例程，以检查是否满足数字条件。
但是，当ab超出整数限制时，会产生伪解。我最终使用如下代码来检查这个:
unsigned long b, c, c_test;
...
c_test=c*b; // Possible overflow
if (c_test/b != c) {/* There has been an overflow*/}
else c=c_test; // No overflow
是否有更好的方法来测试溢出?我知道有些芯片有一个内部标志，在溢出发生时设置，但我从未见过通过C或c++访问它。
注意，有符号int溢出在C和c++中是未定义的行为，因此您必须在不实际引起它的情况下检测它。对于加法前的有符号整型溢出，请参见在C/ c++中检测有符号溢出。
当前回答
尝试这个宏来测试32位机器的溢出位(改编自Angel Sinigersky的解决方案)
#define overflowflag(isOverflow){ \
size_t eflags; \
asm ("pushfl ;" \
"pop %%eax" \
: "=a" (eflags)); \
isOverflow = (eflags >> 11) & 1;}
我将其定义为宏，因为否则溢出位将被覆盖。
下面是上面代码段的一个小应用程序:
#include <cstddef>
#include <stdio.h>
#include <iostream>
#include <conio.h>
#if defined( _MSC_VER )
#include <intrin.h>
#include <oskit/x86>
#endif
using namespace std;
#define detectOverflow(isOverflow){ \
size_t eflags; \
asm ("pushfl ;" \
"pop %%eax" \
: "=a" (eflags)); \
isOverflow = (eflags >> 11) & 1;}
int main(int argc, char **argv) {
bool endTest = false;
bool isOverflow;
do {
cout << "Enter two intergers" << endl;
int x = 0;
int y = 0;
cin.clear();
cin >> x >> y;
int z = x * y;
detectOverflow(isOverflow)
printf("\nThe result is: %d", z);
if (!isOverflow) {
std::cout << ": no overflow occured\n" << std::endl;
} else {
std::cout << ": overflow occured\n" << std::endl;
}
z = x * x * y;
detectOverflow(isOverflow)
printf("\nThe result is: %d", z);
if (!isOverflow) {
std::cout << ": no overflow ocurred\n" << std::endl;
} else {
std::cout << ": overflow occured\n" << std::endl;
}
cout << "Do you want to stop? (Enter \"y\" or \"Y)" << endl;
char c = 0;
do {
c = getchar();
} while ((c == '\n') && (c != EOF));
if (c == 'y' || c == 'Y') {
endTest = true;
}
do {
c = getchar();
} while ((c != '\n') && (c != EOF));
} while (!endTest);
}
其他回答
有一种方法可以确定一个操作是否可能溢出，使用操作数中最高位的位置和一些基本的二进制数学知识。
对于加法，任何两个操作数的结果(最多)比最大操作数的最高1位多1位。例如:
bool addition_is_safe(uint32_t a, uint32_t b) {
size_t a_bits=highestOneBitPosition(a), b_bits=highestOneBitPosition(b);
return (a_bits<32 && b_bits<32);
}
对于乘法，任何两个操作数的结果(最多)是操作数的位数之和。例如:
bool multiplication_is_safe(uint32_t a, uint32_t b) {
size_t a_bits=highestOneBitPosition(a), b_bits=highestOneBitPosition(b);
return (a_bits+b_bits<=32);
}
类似地，你可以像这样估计a的b次方结果的最大大小:
bool exponentiation_is_safe(uint32_t a, uint32_t b) {
size_t a_bits=highestOneBitPosition(a);
return (a_bits*b<=32);
}
(当然，用比特数代替目标整数。)
我不确定确定数字中最高的1位位置的最快方法，这里有一个蛮力方法:
size_t highestOneBitPosition(uint32_t a) {
size_t bits=0;
while (a!=0) {
++bits;
a>>=1;
};
return bits;
}
它不是完美的，但它能让你在做运算之前知道是否有两个数会溢出。我不知道它是否会比您建议的方式检查结果更快，因为highestOneBitPosition函数中的循环，但它可能会(特别是如果您事先知道操作数中有多少位)。
尝试这个宏来测试32位机器的溢出位(改编自Angel Sinigersky的解决方案)
#define overflowflag(isOverflow){ \
size_t eflags; \
asm ("pushfl ;" \
"pop %%eax" \
: "=a" (eflags)); \
isOverflow = (eflags >> 11) & 1;}
我将其定义为宏，因为否则溢出位将被覆盖。
下面是上面代码段的一个小应用程序:
#include <cstddef>
#include <stdio.h>
#include <iostream>
#include <conio.h>
#if defined( _MSC_VER )
#include <intrin.h>
#include <oskit/x86>
#endif
using namespace std;
#define detectOverflow(isOverflow){ \
size_t eflags; \
asm ("pushfl ;" \
"pop %%eax" \
: "=a" (eflags)); \
isOverflow = (eflags >> 11) & 1;}
int main(int argc, char **argv) {
bool endTest = false;
bool isOverflow;
do {
cout << "Enter two intergers" << endl;
int x = 0;
int y = 0;
cin.clear();
cin >> x >> y;
int z = x * y;
detectOverflow(isOverflow)
printf("\nThe result is: %d", z);
if (!isOverflow) {
std::cout << ": no overflow occured\n" << std::endl;
} else {
std::cout << ": overflow occured\n" << std::endl;
}
z = x * x * y;
detectOverflow(isOverflow)
printf("\nThe result is: %d", z);
if (!isOverflow) {
std::cout << ": no overflow ocurred\n" << std::endl;
} else {
std::cout << ": overflow occured\n" << std::endl;
}
cout << "Do you want to stop? (Enter \"y\" or \"Y)" << endl;
char c = 0;
do {
c = getchar();
} while ((c == '\n') && (c != EOF));
if (c == 'y' || c == 'Y') {
endTest = true;
}
do {
c = getchar();
} while ((c != '\n') && (c != EOF));
} while (!endTest);
}
如果您有一个比您想要测试的数据类型大的数据类型(比如您做了一个32位的添加，而您有一个64位的类型)，那么这将检测是否发生溢出。我的例子是一个8位的添加。但它可以放大。
uint8_t x, y; /* Give these values */
const uint16_t data16 = x + y;
const bool carry = (data16 > 0xFF);
const bool overflow = ((~(x ^ y)) & (x ^ data16) & 0x80);
它基于本页解释的概念:http://www.cs.umd.edu/class/spring2003/cmsc311/Notes/Comb/overflow.html
对于一个32位的例子，0xFF变成0xFFFFFFFF, 0x80变成0x80000000，最后uint16_t变成uint64_t。
注意:这捕获整数加法/减法溢出，我意识到你的问题涉及乘法。在这种情况下，分裂可能是最好的办法。这通常是calloc实现确保参数在相乘以获得最终大小时不会溢出的一种方式。
最简单的方法是将unsigned long转换为unsigned long，进行乘法运算，并将结果与0x100000000LL进行比较。
你可能会发现这比你在例子中做除法更有效。
哦，它在C和c++中都可以工作(因为你已经用这两种语言标记了问题)。
我在看glibc手册。这里提到了整数溢出陷阱(FPE_INTOVF_TRAP)作为SIGFPE的一部分。这将是理想的，除了手册中令人讨厌的部分:
FPE_INTOVF_TRAP 整数溢出(在C程序中不可能，除非您以特定于硬件的方式启用溢出捕获)。
真的有点遗憾。
从C23开始，标准头文件<stdckdint.h>提供了以下三个类函数宏:
bool ckd_add(type1 *result, type2 a, type3 b);
bool ckd_sub(type1 *result, type2 a, type3 b);
bool ckd_mul(type1 *result, type2 a, type3 b);
其中type1, type2和type3是任何整数类型。这些函数分别以任意精度对a和b进行加、减或乘，并将结果存储在*result中。如果结果不能由type1精确表示，则函数返回true("计算已溢出")。(任意精确是一种错觉;计算速度非常快，自20世纪90年代初以来几乎所有可用的硬件都可以在一个或两个指令内完成。)
重写OP的例子:
unsigned long b, c, c_test;
// ...
if (ckd_mul(&c_test, c, b))
{
// returned non-zero: there has been an overflow
}
else
{
c = c_test; // returned 0: no overflow
}
C_test包含所有情况下可能溢出的乘法结果。
早在C23之前，GCC 5+和Clang 3.8+就提供了以同样方式工作的内置程序，除了结果指针是最后传递而不是第一个传递:__builtin_add_overflow， __builtin_sub_overflow和__builtin_mul_overflow。这些也适用于小于int的类型。
unsigned long b, c, c_test;
// ...
if (__builtin_mul_overflow(c, b, &c_test))
{
// returned non-zero: there has been an overflow
}
else
{
c = c_test; // returned 0: no overflow
}
Clang 3.4+引入了具有固定类型的算术溢出内置函数，但它们的灵活性要低得多，而且Clang 3.8现在已经可用很长时间了。如果你需要使用__builtin_umull_overflow，尽管有更方便的更新选项。
Visual Studio的cl.exe没有直接的等价物。对于无符号加减法，包括<intrin.h>将允许您使用addcarry_uNN和subborrow_uNN(其中NN是位数，如addcarry_u8或subborrow_u64)。他们的签名有点迟钝:
unsigned char _addcarry_u32(unsigned char c_in, unsigned int src1, unsigned int src2, unsigned int *sum);
unsigned char _subborrow_u32(unsigned char b_in, unsigned int src1, unsigned int src2, unsigned int *diff);
C_in /b_in是输入的进位/借位标志，返回值是输出的进位/借位。它似乎没有符号运算或乘法的等价物。
另外，Clang for Windows现在已经可以投入生产(对于Chrome来说已经足够好了)，所以这也是一个选择。
