开发平台(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++] =
这是undefined behavior 请参考sequence point
作者:
LPH66 (-6.2598534e+18f)
2021-08-31 12:39:00置底十三诫之八
作者:
wawi2 (@@)
2021-08-31 14:02:00听说现在2021年 希望2031不要再有这种问题 虽然这问题我2001就见过
同学去面大M 题目还是有同个 expression 多次对同样变量加减
作者:
MartinJ40 (Martin J-40)
2021-08-31 14:51:00这C++17有规范不是吗？
这种看不出功力的白痴题一堆人很爱考还有operator precedence 也是 是来写软件还是来被课本的阿怎么要考这种 怎么不叫面试者把linux kernel默写下来
更，以前某公司笔试不是考op precedence 是考整题expr evaluation那公司里面暗暗的 感觉会发霉喔对 不是只考一题 是考一堆的最后一题expr evaluation
作者:
ck574b027 (荒围!定厝!贼!妹!)
2021-09-03 04:50:00一模一样耶，484有人以为用置底出题就叫考试
考这个真的很无聊进公司狂写这种code 看看主管爽不爽
要考也应该是考这种code烂在哪边XDC++17虽然有定序了 但我记得C的standard还没定吧?而且不管有没有定 都不会改变这个写法就是烂的事实
作者:
Lipraxde (Lipraxde)
2021-09-06 00:07:00那不好说XD
作者:
sunev (Veritas)
2021-09-06 11:18:00如果是C++17, 这题答案是？
作者:
HMKRL (HMKRL)
2021-09-08 02:32:00就算有定义还是烂写法啊 直接冲击可读性
那就要看看楼上说的“可读性”用的是什么指标了一般常用的 McCabe's CC (Cyclomatic Complexity) 在分行写或并在一起都不会影响复杂度. 那会冲击可读性的点是?
楼上可读性跟复杂度无关阿 变量名称取aaabb123232cc函式名称取djsadoi_jasdj_jasdjadiasd__dasd()复杂度没变 所以你很容易读吗?
没关系啊? 所以哩? 你想表达什么? 不影响复杂度所以跟可读性无关?你的可读性是人读还是编译器读?就算是编译器读 你函式长度也会影响编译器front endlookup token的时间阿所以哪来没影响
我想你可能把 readability 还有 understandability搞混了, 前者只关心语法, 后者在乎的还有语意. 如果你讲到认知负担 (cognitive load) 那还多少有点关系,但如果把 LOC (Line of Code) 增加, 确定真的会减轻认知负担吗? 这就像你说写 raw loop 找阵列最大值,而不是用 max_element(), 哪种比较好? 还是说只要有程式码看不懂, 先说它烂, 可读性差就赢了?
这不是我自己随便定义的, ISO 2502n 就有相关的描述,在我看来这篇文章问的程式码问题并没有很大, 可是却被骂到臭头; 但是更严重的如: int i = 1 << 16; 可能大家都写到无感. 从 security 观点来看还蛮耐人寻味问题没有很大的点在于: 即使把评估顺序调换, 也不会发生存取违规, 因此差别只在读者对语言的熟悉程度
作者:
ck574b027 (荒围!定厝!贼!妹!)
2021-09-09 17:20:00就继续滑坡啊，以函数替换相同功能程式跟滥用postfix是同等级吗。大家也能照样造句：如果减少LOC，真的不会增加认知负担吗？啊不就干话。感谢示范，只要干话接滑坡，人人都可以是辩论大师
作者:
HMKRL (HMKRL)
2021-09-10 01:33:00不会违规存取但会不会造成不符预期的行为？然后i = 1 << 16跟这个你觉得能一眼看懂的人哪边比较多
作者:
protoss (天生散人)
2021-09-10 02:05:00这就很像以前人家推荐圣经本说过的...宁愿一本厚厚的书慢慢翻都没疑问...也不要一本薄薄的越看问题越多...
to HMKRL: 你看懂了 i = 1 << 16, 那有看出不预期行为吗? 它同时有对 bit-pattern, padding, 还有 sizeof(int) 的假设. 但是它好写好读无论是 undefined, implementation-defined, 撰写时当然都需要注意, 才能写出可携的程式码. 但有些很直觉的程式码, 是因为我们强加了很多假设才显得直觉,程式码早已经不可携, 这种情况下才去找那些显而易见的 UB 其实帮助不大
作者:
HMKRL (HMKRL)
2021-09-10 14:23:00我懂你的意思，在跨平台跨环境的状态下这种写法当然可能有问题 但我遇到这类状况甚至会再写明确一点（例如使用int32_t避开int位元数问题）如果是在同一个大家一起开发的平台环境，我想原文写法制造的时间成本绝对大于1<<16
我觉得时间成本因人而异, 就像我举的例子, 对初学者而言, 'A' <= c && c <= 'Z' 比较直觉; 但对有经验的人来说 isupper() 更直觉. 如果就是在确定的编译器版本讨论本文的问题, 我觉得它跟 int 位移的问题没差多少
作者:
HoloLens (GoogleGlass没了ww)
2021-09-10 23:32:00按楼上逻辑一堆style guide都写开心的，没有什么太多是会影响可读性的
style guide 是给没办法把程式码写好的人遵守, 用来确保程式码品质最简单, 也是最后的手段
每个人习惯跟喜欢的style 都有差 style guide 是为了有一个可以参考的基准 跟会不会写无关会写好的人可以有很多种写法
作者:
CoNsTaR ((const *))
2021-09-11 16:13:00举个例子, 为什么交通工具要等红绿灯? 为什么救护车可以闯红绿灯? 重点是追求目标 (软件的可维护性), 而不是方法 (死背规则). 要让组织的人都能写出可理解性高的程式码, 可以投入很多训练, 可以导入自动化工具去侦测/修复错误; 但是维持 coding standard 是最经济的方法, 所以才会普遍. 但不遵守它有没有错? 这要看你只是死背还是可以用不同方法来达成相同目标. 就像这篇推文一样, 每个都说 UB 很烂不要写去背十诫.UB 是什么? UB 有多烂? 不小心写了该怎么办? 是不是只有用力背才可以达成大家的期望?看起来只要把 UB 转个形式就可以绕过背十诫, 那背的效益是? 可以量化它吗?
作者:
CoNsTaR ((const *))
2021-09-12 04:29:00说实话你在这边 roast 版友和版友 grill UB 考题之间的差异也不是很大...然后忍不住吐槽一下，版友从头到尾都在说考这个题目没有鉴别度/考这个题目实务上没什么帮助/考这个很无聊，不知道是怎么被你上纲成 UB 很烂然后在这边跟版友吵的？刚刚才看到有一个版友说那是烂写法，原来你只有在跟他吵误会了，抱歉 orz但并没有像你讲的"这篇推文每个都说 UB"很烂，大家只是 get tired of 这种考题了而已而且我很怀疑像你讲的情况你自己都相不相信，事实就是没有人会因为在意这种写法也是有可行的时候的事实而不想完全不用它，我想大部分人都遇不到 absolutely need 这种写法的情况（我怀疑任何人会遇到）
事实就是连 i + 1 也会踩到 UB, 所以一定遇到, 只是看你有没有意识到, 甚至去避免 UB 带来的影响. 有些UB 特别被重视的原因只是它们比较容易被观察到而已和这题和 coding standard 关联起来其实有点谜, 首先得要知道套用 coding standard 对于维护性有什么帮助, 譬如新人上手的时间 (可理解性), 平均解决 defeat的时间 (可修改性), 这些指标都要建立起来, 并且和套用 coding standard 以前相比有改善, 那么我们才会说coding standarad 对于某公司的某个环境是有帮助的,不然说"避免 XX 的写法比较安全"什么的大部分情况都是自我感觉良好, 如果在侦错的时候还是在用逐步执行, 还是免不了加新的 log, 那怎么写对你而言都没差因为语言的本质, 程式码里存在的 UB 只有多跟少的区别; 并不是有和没有这样单纯的情形
作者:
CoNsTaR ((const *))
2021-09-12 22:34:00我觉得我可能要再重新帮你画一次重点：大家在骂的是每次都考这种考了也不知道能干嘛的题目很烦其实真的不太有人在跟你讨论你个人认为的 UB 真理 best practices 所以，拜托了最后你可能误解我“那种写法”的意思了，我指的是 OP 问的那种写法，不是指 UB in general
难道 UB 还要分"这种" UB 还有"别种" UB 吗? 这才是我的重点. UB 都是一样的, 会觉得"这种"考到烦是开始有差别待遇, 一份至少有 3 个地方会踩到 UB 的程式码, 只纠结执行顺序的问题我也看不出是什么操作
作者:
CoNsTaR ((const *))
2021-09-13 10:58:00orz 你看不出来的操作很简单，是这样的：这些题目 100/100 考的是教授个人以为的 C，不是什么神奇未来 2050 C++ 抽象机器，而在过去目前甚至是可预见的未来的 C 里面，这个 expression 100/100 是 UBmeaning that：1. 对考生来讲这题没有教授要的答案（你根本不知道教授以为的答案是哪一种）2. 这题很无聊/没有鉴别度/考了不知道要干嘛（如版友们的推文不一一列举）然后让我们来回答你提出的问题：1. “难道 UB 还要分这种 UB 和别种 UB 吗”原来是把上次的坡拿来继续滑的部分啊，我懂你的逻辑a. 因为就连像 i+1 这样一般的 expr 都可能是 UB-> b. 所以什么 expr 都可能是 UB-> c. 所以整份 code 到处都是 UB，无法缩小需要检查的范围或是针对某部分 code 找出需要检查的 UB 种类-> d. 所以 UB 就是 UB，没有分这种 UB 那种 UB-> e. 所以不能针对某些特殊（例如100%发生）的 UB 做其他处理，否则就是纠结在某种 UB，而且是对 UB 的差别待遇哇~真是神奇的逻辑呢，如果这不是滑坡什么才是滑坡呢？
XD 他会跟你解释 有一种CPU跟compiler int只有1 bit所以写c语言 int i=2 就会UB 你要注意 XD真的要这样搞 你可以用 configure.sh或是用preprocessor做静态检查就好了 无限延伸这议题有什么用 想到以前工作 也有个工程师很钻牛角尖我写给他chip i2c的函式库给他用 他就在质疑 有没有error hanlding 我说我有做i2c error handle了他继续问 有没有可能i2c写成功 chip register 没改变这有没有检查 或是register值写进去了 示波器量出来没变 这有没有做error handing....我当场无言...
作者:
CoNsTaR ((const *))
2021-09-13 21:23:00合理怀疑楼上是在钓 L 大出来指正 int 大小规范
作者:
Lipraxde (Lipraxde)
2021-09-13 21:27:00是在写火箭发射器腻XD
要挑剔UB 原文的例子也太多 讲不玩了谁说 int A[3] = {0, 0, 0} 一定会成功?搞不好程式根本没stack size了 一宣告变量就爆了还有print字串那么长 万一机器只有12byte 内存怎么办