整数运算这件事几乎每个学C语言的人都要在某个在线判题平台上被它教育一遍。标题里这个整数简单运算看着平平无奇实际上它是一类题目的统称——给两个整数让你做加、减、乘、除、取余然后按格式输出。很多人第一次提交就WAWrong Answer盯着代码看半天逻辑明明没错问题却出在别的地方。这篇内容就是围绕这类上机题展开的把整数运算里那些看着简单、实际有坑的地方一次讲透包括输入输出的格式陷阱、整数除法的截断行为、取余的符号规则、溢出的边界处理以及判题系统对输出格式的苛刻要求。适合刚接触C语言、正在刷上机题的同学也适合已经写过一些代码但总在细节上翻车的人。我会用从业者踩坑的视角来讲不讲教科书式的定义只讲你真正会遇到的麻烦和解决办法。1. 为什么简单运算反而是WA重灾区1.1 题目越简单判题系统越较真很多人有个错觉题目描述越短代码越好写。实际情况恰恰相反。像输入两个整数输出它们的和、差、积、商、余数这种题逻辑复杂度几乎为零但判题系统对输出格式的要求却精确到字符级别。多一个空格、少一个换行、中文冒号写成英文冒号统统判错。我见过太多这样的情况代码逻辑完全正确本地跑出来结果也对提交上去就是WA。原因往往不是算法而是输出格式和题目要求差了哪怕一个字符。这类题目的判题方式通常是逐字符比对你的输出必须和标准答案的字节流完全一致包括行末是否有空格、最后一行是否有换行符。举个典型的坑题目要求输出abc这样的格式你写成了printf(%d%d%d\n, a, b, ab);看起来没问题。但如果题目实际要求的是每个结果单独一行或者要求用空格分隔而不是等号那就全错了。所以做这类题第一件事不是写代码而是把题目里的输出格式要求逐字读三遍把样例输入输出对照着看确认分隔符、换行、标点符号到底是什么。提示判题系统不会告诉你格式错误它只会返回WA。所以格式问题只能靠你自己对照样例排查这是这类题最耗时间的地方。1.2 样例通过不等于全部通过另一个高频误区是样例过了就万事大吉。样例通常只覆盖最普通的情况比如两个正数。但判题系统的测试数据里往往藏着负数、零、大数、边界值。你的代码在样例上跑得漂亮一提交就挂多半是没考虑这些隐藏情况。以整数除法为例样例给的是7 2你算出3没问题。但测试数据里可能有-7 2C语言的整数除法是向零截断的-7/2的结果是-3而不是-4。如果你脑子里想的是数学上的向下取整就会对结果产生误判。再比如除数为零的情况虽然多数题目会保证除数非零但有些题会故意给0来测试你的程序会不会崩溃。所以我的习惯是写完代码后自己构造几组刁钻的输入——负数、零、一正一负、接近int上限的大数——手动跑一遍看看结果是否符合预期。这一步花不了几分钟但能挡掉大部分隐藏的WA。1.3 整数运算里最容易被忽视的三个行为在动手写代码之前有三个C语言整数运算的固有行为必须先搞清楚它们直接决定了你的结果对不对运算类型行为规则典型陷阱整数除法向零截断丢弃小数部分-7/2 -3不是-4取余运算余数符号与被除数相同-7%2 -1不是1整数溢出超出int范围后回绕大数相乘结果变成负数这三条规则每一条都能让逻辑正确的代码输出错误答案。下面几个章节会逐一拆开讲配合具体的代码和验证方法。2. 输入输出格式判题系统的第一道关卡2.1 scanf的读入陷阱与返回值检查读两个整数最直接的写法是scanf(%d %d, a, b);。这行代码本身没问题但有几个细节值得说。首先是格式字符串里的空格。%d %d中间的空格在scanf里表示跳过任意数量的空白字符包括空格、制表符、换行。所以用户输入3 5、3 5、甚至3回车5都能正确读入。这一点很多人不知道以为空格必须严格匹配其实scanf对空白是宽容的。但scanf有个更隐蔽的问题它不检查输入是否成功。如果输入格式不对比如该读整数的地方来了个字母scanf会失败而a和b里可能是未初始化的垃圾值。在判题环境里输入通常规范但养成检查返回值的习惯没坏处if (scanf(%d %d, a, b) ! 2) { return 1; // 读入失败直接退出 }scanf返回成功读入的项数这里期望是2。虽然上机题一般不需要这么严谨但这是好习惯尤其在你自己调试的时候能快速发现为什么结果是乱码——多半是读入失败了。还有一个常见错误是漏写取地址符。scanf(%d, a)而不是scanf(%d, a)编译器可能只给个警告程序运行时直接崩溃或读到错误地址。这个错误新手特别容易犯而且因为编译能过排查起来很费劲。2.2 printf的输出格式必须逐字符对齐输出是这类题最容易翻车的地方。题目要求什么格式你就得输出什么格式一个字符都不能差。常见的格式要求有这么几种每个结果单独一行printf(%d\n%d\n, ab, a-b);用空格分隔printf(%d %d\n, ab, a-b);带文字说明printf(sum%d\n, ab);关键在于看清楚题目给的样例输出。样例输出里有没有空格、有没有换行、文字部分用的是什么符号全部照抄。我一般会把样例输出复制到记事本里打开显示所有字符功能确认行末到底有没有多余空格。这里有个特别隐蔽的坑行末空格。有些题目要求输出a b c三个数用空格分隔你写成printf(%d %d %d\n, x, y, z);最后一个数后面没有空格这是对的。但如果你写成循环输出printf(%d , x);最后一个数后面就会多一个空格判题系统可能因此判错。解决办法是最后一个元素单独处理或者用条件判断控制空格。// 错误写法末尾多一个空格 for (int i 0; i 3; i) { printf(%d , arr[i]); } // 正确写法最后一个不带空格 for (int i 0; i 3; i) { printf(%d, arr[i]); if (i 2) printf( ); }注意不同判题系统对行末空格的处理不一样有的会忽略有的严格比对。稳妥起见一律按不多输出任何字符来写。2.3 换行符与平台差异还有一个容易被忽略的点换行符。在Windows上文本文件的换行是\r\n两个字符在Linux上换行是\n一个字符。判题系统通常跑在Linux环境你用printf(\n)输出的是\n没问题。但如果你在Windows下用某些编辑器保存文件或者手动输入了\r就可能出问题。不过对于纯代码提交的判题系统这个一般不用担心因为你的\n在编译后就是\n。真正需要注意的是不要多输出换行。比如题目要求输出一行结果你习惯性地在最后多写一个printf(\n);就多了一个空行可能被判错。我的经验是输出格式严格对照样例样例有几行你就输出几行样例末尾有没有空行你就跟着来。不确定的时候宁可少输出一个换行也不要多输出。3. 整数除法与取余符号规则是最大的坑3.1 整数除法的向零截断C语言里两个整数相除结果还是整数小数部分直接丢弃。这个丢弃的方向是向零取整也就是往数轴原点方向靠。正数除法好理解7/23因为3.5截断成3。负数就不直观了-7/2数学上是-3.5向零截断得到-3而不是向下取整的-4。这个规则在判题时经常被用来设陷阱。比如题目让你算两个数的商测试数据里放一组-7 2标准答案是-3。如果你用浮点数算完再转int或者脑子里按数学取整来想就可能写出错误的结果。验证方法很简单写个小程序跑一下#include stdio.h int main() { printf(%d\n, -7 / 2); // 输出 -3 printf(%d\n, 7 / -2); // 输出 -3 printf(%d\n, -7 / -2); // 输出 3 return 0; }三组结果都是向零截断。记住这个行为遇到负数除法就不会想当然。3.2 取余运算的符号跟随被除数取余的规则比除法更容易记混。C语言里a % b的结果符号跟a被除数一致和b除数无关。所以7 % 2 1-7 % 2 -1符号跟-77 % -2 1符号跟7-7 % -2 -1符号跟-7这个规则和数学上余数非负的约定不一样很多人第一次遇到会懵。判题系统如果考负数取余标准答案就是按C语言的规则来的你按数学规则算反而错。有个实用的记忆口诀余数的绝对值小于除数的绝对值符号看被除数。写代码时如果对结果没把握直接打印出来验证别靠脑补。3.3 除零与取余零的崩溃问题整数除法里除数不能为零否则程序直接崩溃运行时错误通常是SIGFPE信号。取余也一样a % 0同样会崩。多数上机题会明确说保证除数不为零但有些题不保证或者故意用零来测试你的防御性。稳妥的做法是在运算前判断if (b ! 0) { printf(%d %d\n, a / b, a % b); } else { // 按题目要求处理比如输出特定提示或跳过 }题目怎么要求就怎么处理但至少你的程序不能崩。判题系统遇到程序崩溃返回的通常是RERuntime Error和WA是两种不同的错误排查方向也不一样。4. 溢出与边界int装不下的时候怎么办4.1 int的取值范围与溢出回绕C语言里int通常是32位取值范围是-2147483648到2147483647也就是大约正负21亿。两个整数做加法或乘法结果一旦超出这个范围就会溢出回绕——结果变成一个完全不相干的数通常是负数。比如2000000000 2000000000数学上是40亿但int装不下实际结果是-294967296。这种错误在样例里看不出来样例通常是小数字但测试数据里一旦有大数就暴露了。判断会不会溢出可以在运算前估算如果a和b都是正数且a INT_MAX - b那么ab就会溢出。乘法更复杂需要判断a INT_MAX / b。不过对于简单运算这类题如果题目没说要处理大数通常测试数据在int范围内不用过度设计。但如果你不确定用long long更保险。4.2 用long long兜底的取舍long long是64位整数范围到约正负9.2×10^18基本能装下绝大多数上机题的数据。把变量声明成long long输入输出用%lld就能避免大部分溢出问题。#include stdio.h int main() { long long a, b; scanf(%lld %lld, a, b); printf(%lld\n, a b); return 0; }代价是内存占用翻倍但对于这种小题完全无所谓。我的建议是如果题目数据范围接近或超过10^9直接用long long别在int上赌。多写几个字符省去排查溢出的时间这笔账很划算。不过要注意long long的输入输出格式符是%lld用错了比如用%d读long long会导致读入错误而且编译器不一定报错排查起来很痛苦。这是用long long唯一需要小心的地方。4.3 边界值的自测清单写完代码我习惯用下面这组边界值自测一遍能覆盖大部分隐藏陷阱测试类型输入示例关注点正数常规7 2基本正确性负数除法-7 2截断方向负数取余-7 2余数符号除数为负7 -2商和余数符号含零0 5零参与运算大数2000000000 2000000000是否溢出相等5 5商为1余为0这七组跑下来没问题基本可以放心提交。花两分钟自测比提交后反复WA再回头找问题高效得多。5. 一套可复用的提交前检查流程5.1 从读题到提交的固定动作刷这类简单运算题我总结了一套固定流程每次按顺序走一遍能挡掉九成以上的低级错误逐字读输出格式把题目要求的输出格式和样例输出对照确认分隔符、换行、文字说明。确认数据范围看题目有没有给数据范围接近int上限就用long long。写核心运算加减乘除取余注意除法和取余的符号规则。加除零判断如果题目不保证除数非零加个if。本地跑样例样例输入输出必须完全一致。跑边界自测用上一节的七组数据过一遍。检查行末空格和多余换行对照样例不多输出任何字符。这套流程走下来一道简单运算题从读到提交不超过十分钟而且返工率极低。5.2 常见错误对照表把这类题的高频错误整理成表提交前扫一眼对号入座错误现象可能原因排查方向WA样例却通过隐藏测试数据含负数/大数检查除余符号、溢出WA格式看着对行末空格或多余换行逐字符比对样例RE运行时错误除数为零加除零判断结果乱码scanf漏写或格式符错检查读入语句大数结果变负数int溢出改用long long这张表基本覆盖了整数简单运算类题目的所有常见故障。遇到问题先查表比盲目改代码快得多。5.3 关于简单题的心态最后说点实在的。这类题目的价值不在于算法难度而在于训练你对细节的敏感度。真正写工程代码的时候整数除法的截断、取余的符号、溢出的处理这些简单的知识点天天都在用。上机题把它们单独拎出来考就是逼你把基础打扎实。我见过不少人觉得这种题太简单不值得认真结果在真实项目里因为一个整数除法写错方向排查了大半天。基础不牢后面全是坑。所以别嫌题简单把每一道都当成练基本功的机会格式抠到字符级边界想到极端值这个习惯养成了受益的是后面所有代码。提示如果判题系统支持查看测试点信息有些会显示第几个测试点错了一定要利用起来。错在第几个点往往能反推出是哪类数据出了问题比盲猜高效得多。
