作者CaliforCat (Cal)
看板C_and_CPP
标题[问题] A[x++] = --x
时间Tue Aug 31 12:08:53 2021
开发平台(Platform): (Ex: Win10, Linux, ...)
Win10
编译器(Ex: GCC, clang, VC++...)+目标环境(跟开发平台不同的话需列出)
GCC
额外使用到的函数库(Library Used): (Ex: OpenGL, ...)
问题(Question)：
遇到题目问这题的输出，我的想法是先将x=x-1
後续就不太知道该怎麽判断，而且用两个ide跑出的结果不同
int main()
{
int A[3] = {0, 0, 0};
int x = 1;
A[x++] = --x;
printf("A[0]=%d, A[1]=%d, A[2]=%d", A[0], A[1], A[2]);
}
喂入的资料(Input)：
无
预期的正确结果(Expected Output)：
用code block跑出来是
A[0]=1, A[1]=0, A[2]=0
https://i.imgur.com/3UGzFqf.jpg
用线上ide codechef跑出来是
A[0]=0, A[1]=1, A[2]=0
https://i.imgur.com/oYd3YFB.jpg
错误结果(Wrong Output)：
程式码(Code)：(请善用置底文网页, 记得排版，禁止使用图档)
已於上述列出
麻烦各位大大 谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.255.127 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1630382935.A.E4F.html
1F：→ peterbrucele: 这是undefined behavior 请参考sequence point08/31 12:12
2F：推 LPH66: 置底十三诫之八08/31 12:39
3F：嘘 wawi2: 听说现在2021年 希望2031不要再有这种问题 虽然这问题我20008/31 14:02
4F：→ wawi2: 1就见过08/31 14:02
题目不是我出的啊大哥，遇到我也很困扰，不知道怎麽解
5F：推 b0920075: 同学去面大M 题目还是有同个 expression 多次对同样变08/31 14:24
6F：→ b0920075: 数加减08/31 14:24
这种真的是各种考试很爱考
7F：→ MartinJ40: 这C++17有规范不是吗？08/31 14:51
※ 编辑: CaliforCat (114.136.255.127 台湾), 08/31/2021 16:33:27
8F：嘘 d630200x: 垃圾题，但我想台湾2041还会继续出这种题目 08/31 18:09
9F：推 a27417332: 谢谢楼上M大提点，翻了规格跟置底以後才发现QQ 08/31 20:31
10F：推 pponywong: 这种看不出功力的白痴题一堆人很爱考 09/02 12:47
11F：→ pponywong: 还有operator precedence 也是 是来写软体还是来 09/02 12:47
12F：→ pponywong: 被课本的阿 09/02 12:48
13F：→ pponywong: 怎麽要考这种 怎麽不叫面试者把linux kernel默写下来 09/02 12:48
14F：→ MOONRAKER: 更，以前某公司笔试不是考op precedence 是考整题 09/02 14:40
15F：→ MOONRAKER: expr evaluation 09/02 14:40
16F：→ MOONRAKER: 那公司里面暗暗的 感觉会发霉 09/02 14:41
17F：→ MOONRAKER: 喔对 不是只考一题 是考一堆的最後一题expr evaluation 09/02 14:42
18F：→ MasterChang: 不该写出这种code的题目实在不该出.... 09/03 01:03
19F：→ ck574b027: 一模一样耶，484有人以为用置底出题就叫考试 09/03 04:50
20F：推 xiao2chen: 考这个真的很无聊 09/03 12:56
21F：→ xiao2chen: 进公司狂写这种code 看看主管爽不爽 09/03 12:57
22F：→ sarafciel: 要考也应该是考这种code烂在哪边XD 09/03 13:43
23F：→ sarafciel: C++17虽然有定序了 但我记得C的standard还没定吧? 09/03 13:45
24F：→ sarafciel: 而且不管有没有定 都不会改变这个写法就是烂的事实 09/03 13:46
25F：推 cuteSquirrel: 鸟题目+1 实务上code review不会过 09/05 17:32
26F：→ Lipraxde: 那不好说XD 09/06 00:07
27F：推 sunev: 如果是C++17, 这题答案是？ 09/06 11:18
28F：推 pionlang5566: 应该查记录看这行垃圾是谁写的 然後拿棒球棍揍他 09/07 06:34
29F：推 cuteSquirrel: 结果发现是经理 XDDDDD 09/07 11:48
30F：推 HMKRL: 就算有定义还是烂写法啊 直接冲击可读性 09/08 02:32
31F：→ loveme00835: 那就要看看楼上说的「可读性」用的是什麽指标了 09/08 17:16
32F：推 loveme00835: 一般常用的 McCabe's CC (Cyclomatic Complexity) 在 09/08 17:23
33F：→ loveme00835: 分行写或并在一起都不会影响复杂度. 那会冲击可读性 09/08 17:23
34F：→ loveme00835: 的点是? 09/08 17:23
35F：推 pponywong: 楼上可读性跟复杂度无关阿 变数名称取aaabb123232cc 09/09 07:33
36F：→ pponywong: 函式名称取djsadoi_jasdj_jasdjadiasd__dasd() 09/09 07:33
37F：→ pponywong: 复杂度没变 所以你很容易读吗? 09/09 07:34
38F：→ loveme00835: 数值计算和命名风格有什麽关系? 09/09 08:10
39F：推 pponywong: 没关系啊? 所以哩? 你想表达什麽? 不影响复杂度所以 09/09 08:23
40F：→ pponywong: 跟可读性无关? 09/09 08:23
41F：→ pponywong: 你的可读性是人读还是编译器读? 09/09 08:24
42F：推 pponywong: 就算是编译器读 你函式长度也会影响编译器front end 09/09 08:27
43F：→ pponywong: lookup token的时间阿 09/09 08:27
44F：→ pponywong: 所以哪来没影响 09/09 08:28
45F：→ loveme00835: 我想你可能把 readability 还有 understandability 09/09 12:19
46F：→ loveme00835: 搞混了, 前者只关心语法, 後者在乎的还有语意. 如果 09/09 12:19
47F：→ loveme00835: 你讲到认知负担 (cognitive load) 那还多少有点关系, 09/09 12:21
48F：→ loveme00835: 但如果把 LOC (Line of Code) 增加, 确定真的会减轻 09/09 12:22
49F：→ loveme00835: 认知负担吗? 这就像你说写 raw loop 找阵列最大值, 09/09 12:23
50F：→ loveme00835: 而不是用 max_element(), 哪种比较好? 还是说只要有 09/09 12:24
51F：→ loveme00835: 程式码看不懂, 先说它烂, 可读性差就赢了? 09/09 12:24
52F：推 pponywong: ... whatever 你的定义随便一说 09/09 13:26
53F：→ loveme00835: 这不是我自己随便定义的, ISO 2502n 就有相关的描述, 09/09 15:13
54F：→ loveme00835: 在我看来这篇文章问的程式码问题并没有很大, 可是却 09/09 15:13
55F：→ loveme00835: 被骂到臭头; 但是更严重的如: int i = 1 << 16; 可能 09/09 15:14
56F：→ loveme00835: 大家都写到无感. 从 security 观点来看还蛮耐人寻味 09/09 15:15
57F：→ loveme00835: 问题没有很大的点在於: 即使把评估顺序调换, 也不会 09/09 15:21
58F：→ loveme00835: 发生存取违规, 因此差别只在读者对语言的熟悉程度 09/09 15:23
59F：→ ck574b027: 就继续滑坡啊，以函数替换相同功能程式跟滥用postfix 09/09 17:20
60F：→ ck574b027: 是同等级吗。大家也能照样造句：如果减少LOC，真的不 09/09 17:20
61F：→ ck574b027: 会增加认知负担吗？啊不就干话。感谢示范，只要干话 09/09 17:20
62F：→ ck574b027: 接滑坡，人人都可以是辩论大师 09/09 17:20
63F：推 HMKRL: 不会违规存取但会不会造成不符预期的行为？然後i = 1 << 16 09/10 01:33
64F：→ HMKRL: 跟这个你觉得能一眼看懂的人哪边比较多 09/10 01:33
65F：→ protoss: 这就很像以前人家推荐圣经本说过的...宁愿一本厚厚的书慢 09/10 02:05
66F：→ protoss: 慢翻都没疑问...也不要一本薄薄的越看问题越多... 09/10 02:05
67F：→ loveme00835: to HMKRL: 你看懂了 i = 1 << 16, 那有看出不预期行 09/10 10:17
68F：→ loveme00835: 为吗? 它同时有对 bit-pattern, padding, 还有 sizeo 09/10 10:17
69F：→ loveme00835: f(int) 的假设. 但是它好写好读 09/10 10:17
70F：推 loveme00835: 无论是 undefined, implementation-defined, 撰写时 09/10 10:21
71F：→ loveme00835: 当然都需要注意, 才能写出可携的程式码. 但有些很直 09/10 10:22
72F：→ loveme00835: 觉的程式码, 是因为我们强加了很多假设才显得直觉, 09/10 10:23
73F：→ loveme00835: 程式码早已经不可携, 这种情况下才去找那些显而易见 09/10 10:23
74F：→ loveme00835: 的 UB 其实帮助不大 09/10 10:24
75F：推 HMKRL: 我懂你的意思，在跨平台跨环境的状态下这种写法当然可能有 09/10 14:23
76F：→ HMKRL: 问题 但我遇到这类状况甚至会再写明确一点（例如使用int32_ 09/10 14:23
77F：→ HMKRL: t避开int位元数问题） 09/10 14:23
78F：→ HMKRL: 如果是在同一个大家一起开发的平台环境，我想原文写法制造 09/10 14:23
79F：→ HMKRL: 的时间成本绝对大於1<<16 09/10 14:23
80F：→ loveme00835: 我觉得时间成本因人而异, 就像我举的例子, 对初学者 09/10 14:57
81F：→ loveme00835: 而言, 'A' <= c && c <= 'Z' 比较直觉; 但对有经验 09/10 14:58
82F：→ loveme00835: 的人来说 isupper() 更直觉. 如果就是在确定的编译器 09/10 15:00
83F：→ loveme00835: 版本讨论本文的问题, 我觉得它跟 int 位移的问题没 09/10 15:01
84F：→ loveme00835: 差多少 09/10 15:02
85F：推 HoloLens: 按楼上逻辑一堆style guide都写开心的，没有甚麽太多是 09/10 23:32
86F：→ HoloLens: 会影响可读性的 09/10 23:32
87F：→ loveme00835: style guide 是给没办法把程式码写好的人遵守, 用来 09/11 02:04
88F：→ loveme00835: 确保程式码品质最简单, 也是最後的手段 09/11 02:04
89F：推 steve1012: 每个人习惯跟喜欢的style 都有差 style guide 是为了 09/11 12:44
90F：→ steve1012: 有一个可以参考的基准 跟会不会写无关 09/11 12:44
91F：→ steve1012: 会写好的人可以有很多种写法 09/11 12:44
92F：推 CoNsTaR: L 大的推文不知道为什麽有种这个的既视感 09/11 16:13
94F：→ loveme00835: 举个例子, 为什麽交通工具要等红绿灯? 为什麽救护车 09/11 18:13
95F：→ loveme00835: 可以闯红绿灯? 重点是追求目标 (软体的可维护性), 而 09/11 18:14
96F：→ loveme00835: 不是方法 (死背规则). 要让组织的人都能写出可理解性 09/11 18:15
97F：→ loveme00835: 高的程式码, 可以投入很多训练, 可以导入自动化工具 09/11 18:16
98F：→ loveme00835: 去侦测/修复错误; 但是维持 coding standard 是最经 09/11 18:17
99F：→ loveme00835: 济的方法, 所以才会普遍. 但不遵守它有没有错? 这要 09/11 18:18
100F：→ loveme00835: 看你只是死背还是可以用不同方法来达成相同目标. 就 09/11 18:20
101F：→ loveme00835: 像这篇推文一样, 每个都说 UB 很烂不要写去背十诫. 09/11 18:21
102F：→ loveme00835: UB 是什麽? UB 有多烂? 不小心写了该怎麽办? 是不是 09/11 18:23
103F：→ loveme00835: 只有用力背才可以达成大家的期望? 09/11 18:24
104F：→ loveme00835: 看起来只要把 UB 转个形式就可以绕过背十诫, 那背的 09/11 18:50
105F：→ loveme00835: 效益是? 可以量化它吗? 09/11 18:50
106F：推 CoNsTaR: 说实话你在这边 roast 版友和版友 grill UB 考题之间的差 09/12 04:29
107F：→ CoNsTaR: 异也不是很大... 09/12 04:29
108F：→ CoNsTaR: 然後忍不住吐槽一下，版友从头到尾都在说考这个题目没有 09/12 04:29
109F：→ CoNsTaR: 监别度/考这个题目实务上没什麽帮助/考这个很无聊，不知 09/12 04:29
110F：→ CoNsTaR: 道是怎麽被你上纲成 UB 很烂然後在这边跟版友吵的？ 09/12 04:29
111F：推 CoNsTaR: 刚刚才看到有一个版友说那是烂写法，原来你只有在跟他吵 09/12 04:38
112F：→ CoNsTaR: 误会了，抱歉 orz 09/12 04:38
113F：→ CoNsTaR: 但并没有像你讲的"这篇推文每个都说 UB"很烂，大家只是 g 09/12 04:43
114F：→ CoNsTaR: et tired of 这种考题了而已 09/12 04:43
115F：→ CoNsTaR: 而且我很怀疑像你讲的情况你自己都相不相信，事实就是没 09/12 04:52
116F：→ CoNsTaR: 有人会因为在意这种写法也是有可行的时候的事实而不想完 09/12 04:52
117F：→ CoNsTaR: 全不用它，我想大部分人都遇不到 absolutely need 这种写 09/12 04:52
118F：→ CoNsTaR: 法的情况（我怀疑任何人会遇到） 09/12 04:52
119F：→ loveme00835: 事实就是连 i + 1 也会踩到 UB, 所以一定遇到, 只是 09/12 13:45
120F：→ loveme00835: 看你有没有意识到, 甚至去避免 UB 带来的影响. 有些 09/12 13:47
121F：→ loveme00835: UB 特别被重视的原因只是它们比较容易被观察到而已 09/12 13:48
122F：→ loveme00835: 和这题和 coding standard 关联起来其实有点谜, 首先 09/12 13:50
123F：→ loveme00835: 得要知道套用 coding standard 对於维护性有什麽帮助 09/12 13:50
124F：→ loveme00835: , 譬如新人上手的时间 (可理解性), 平均解决 defeat 09/12 13:51
125F：→ loveme00835: 的时间 (可修改性), 这些指标都要建立起来, 并且和套 09/12 13:51
126F：→ loveme00835: 用 coding standard 以前相比有改善, 那麽我们才会说 09/12 13:52
127F：→ loveme00835: coding standarad 对於某公司的某个环境是有帮助的, 09/12 13:52
128F：→ loveme00835: 不然说"避免 XX 的写法比较安全"什麽的大部分情况都 09/12 13:54
129F：→ loveme00835: 是自我感觉良好, 如果在侦错的时候还是在用逐步执行 09/12 13:55
130F：→ loveme00835: , 还是免不了加新的 log, 那怎麽写对你而言都没差 09/12 13:55
131F：→ loveme00835: 因为语言的本质, 程式码里存在的 UB 只有多跟少的区 09/12 14:29
132F：→ loveme00835: 别; 并不是有和没有这样单纯的情形 09/12 14:29
133F：推 CoNsTaR: 我觉得我可能要再重新帮你画一次重点： 09/12 22:34
134F：→ CoNsTaR: 大家在骂的是每次都考这种考了也不知道能干嘛的题目很烦 09/12 22:34
135F：→ CoNsTaR: 其实真的不太有人在跟你讨论你个人认为的 UB 真理 best p 09/12 22:34
136F：→ CoNsTaR: ractices 所以，拜托了 09/12 22:34
137F：→ CoNsTaR: 最後你可能误解我“那种写法”的意思了，我指的是 OP 问 09/12 22:34
138F：→ CoNsTaR: 的那种写法，不是指 UB in general 09/12 22:34
139F：推 loveme00835: 难道 UB 还要分"这种" UB 还有"别种" UB 吗? 这才是 09/12 22:57
140F：→ loveme00835: 我的重点. UB 都是一样的, 会觉得"这种"考到烦是开始 09/12 22:57
141F：→ loveme00835: 有差别待遇, 一份至少有 3 个地方会踩到 UB 的程式码 09/12 22:57
142F：→ loveme00835: , 只纠结执行顺序的问题我也看不出是什麽操作 09/12 22:57
143F：推 CoNsTaR: orz 你看不出来的操作很简单，是这样的： 09/13 10:58
144F：→ CoNsTaR: 这些题目 100/100 考的是教授个人以为的 C，不是什麽神奇 09/13 10:58
145F：→ CoNsTaR: 未来 2050 C++ 抽象机器，而在过去目前甚至是可预见的未 09/13 10:58
146F：→ CoNsTaR: 来的 C 里面，这个 expression 100/100 是 UB 09/13 10:58
147F：→ CoNsTaR: meaning that： 09/13 10:58
148F：→ CoNsTaR: 1. 对考生来讲这题没有教授要的答案 09/13 10:58
149F：→ CoNsTaR: （你根本不知道教授以为的答案是哪一种） 09/13 10:58
150F：→ CoNsTaR: 2. 这题很无聊/没有监别度/考了不知道要干嘛 09/13 10:58
151F：→ CoNsTaR: （如版友们的推文不一一列举） 09/13 10:58
152F：→ CoNsTaR: 然後让我们来回答你提出的问题： 09/13 10:58
153F：→ CoNsTaR: 1. 「难道 UB 还要分这种 UB 和别种 UB 吗」 09/13 10:58
154F：→ CoNsTaR: 原来是把上次的坡拿来继续滑的部分啊，我懂你的逻辑 09/13 10:58
155F：→ CoNsTaR: a. 因为就连像 i+1 这样一般的 expr 都可能是 UB 09/13 10:58
156F：→ CoNsTaR: -> b. 所以什麽 expr 都可能是 UB 09/13 10:58
157F：→ CoNsTaR: -> c. 所以整份 code 到处都是 UB，无法缩小需要检查的范 09/13 10:58
158F：→ CoNsTaR: 围或是针对某部分 code 找出需要检查的 UB 种类 09/13 10:58
159F：→ CoNsTaR: -> d. 所以 UB 就是 UB，没有分这种 UB 那种 UB 09/13 10:58
160F：→ CoNsTaR: -> e. 所以不能针对某些特殊（例如100%发生）的 UB 做其 09/13 10:58
161F：→ CoNsTaR: 他处理，否则就是纠结在某种 UB，而且是对 UB 的差别待遇 09/13 10:58
162F：→ CoNsTaR: 哇~真是神奇的逻辑呢，如果这不是滑坡什麽才是滑坡呢？ 09/13 10:58
163F：推 pponywong: XD 他会跟你解释 有一种CPU跟compiler int只有1 bit 09/13 11:05
164F：→ pponywong: 所以写c语言 int i=2 就会UB 你要注意 XD 09/13 11:06
165F：→ pponywong: 真的要这样搞 你可以用 configure.sh 09/13 11:07
166F：→ pponywong: 或是用preprocessor做静态检查就好了 无限延伸这议题 09/13 11:08
167F：→ pponywong: 有什麽用 想到以前工作 也有个工程师很钻牛角尖 09/13 11:09
168F：→ pponywong: 我写给他chip i2c的函式库给他用 他就在质疑 有没有 09/13 11:10
169F：→ pponywong: error hanlding 我说我有做i2c error handle了 09/13 11:10
170F：→ pponywong: 他继续问 有没有可能i2c写成功 chip register 没改变 09/13 11:11
171F：→ pponywong: 这有没有检查 或是register值写进去了 示波器量出来 09/13 11:12
172F：→ pponywong: 没变 这有没有做error handing....我当场无言... 09/13 11:12
173F：推 CoNsTaR: 合理怀疑楼上是在钓 L 大出来指正 int 大小规范 09/13 21:23
174F：→ Lipraxde: 是在写火箭发射器腻XD 09/13 21:27
175F：推 pponywong: 要挑剔UB 原文的例子也太多 讲不玩了 09/13 22:23
176F：→ pponywong: 谁说 int A[3] = {0, 0, 0} 一定会成功? 09/13 22:23
177F：→ pponywong: 搞不好程式根本没stack size了 一宣告变数就爆了 09/13 22:24
178F：推 pponywong: 还有print字串那麽长 万一机器只有12byte 记忆体怎麽办 09/13 22:29
179F：推 iLeyaSin365: 现实谁会这样写？XD想知道 09/14 07:18