開發平台(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 記憶體怎麼辦