Re: [閒聊] i++ is undefined behavior?

看板Soft_Job作者 (阿毛)時間9年前 (2015/04/25 13:30), 編輯推噓13(13推 0噓 100→)
留言113則, 17人參與, 最新討論串4/6 (看更多)
※ 引述《pttworld (批踢踢世界)》之銘言： : 觀念上，++operand和operand++在同一個statement才會的。 : 然而仍取決於實作的compiler。 : 不存在那種寫法比較高明或要逼死誰？！ : 寫法是對programmer來說的， : 對機器沒差。 : ※ 引述《ah7675 (阿懋)》之銘言： : : 最近因為同事在code review時表示 i++會隨編譯器實作而有不同行為 : : 所以要求我不要用這種寫法，到這邊應該很多人會說："沒錯啊，這你都不懂？" : : 關鍵在於他舉的例子是這樣的 : : i=10; : : val = array[i++]; : : val equals array[10] or array[11]? : : 我整個傻住了，我的理解是，答案絕對是val=array[10] : : 而隨編譯器會變化的地方是，在該expression/statement所構成的 : : 數個指令中"遞增"的時機可能不同，所以如果在一個expression中存取i : : 兩次以上會造成未定義行為 : : 但suffix increament operator必定是先return再遞增 : : 請問我的理解才是錯的嗎？ : : 那GLIBC裡的strcmp實作也是不可靠的嗎？ : : https://fossies.org/dox/glibc-2.21/string_2strcmp_8c_source.html : : 還有另一個例子是說const global variable is better than Macro?? : : 理由是global variable只有一份、用再多次也只是reference同一份 : : 但是macro假設被使用10次就會造成code size增加10倍 : : 用來舉例的型別是int : : 這也是顛覆了我一直以來的觀念，讓我相當震撼 : : 我應該趕快請前輩喝飲料順便多請教他，還是趁試用期還沒過趕快離職？ : : 請各位給我一些意見，感謝！ 經過一串討論我又更震驚了...... 原來glibc裡strcmp那種寫法對大多數人來說是華而不實 艱澀難懂又容易產生bug，平常真的沒人用這種寫法嗎？ 本身是做embedded的，從bootloader到kernel到上層ap都有經驗(Linux) 學生時代也有Windows開發經驗(VS2008 MFC/Qt) 經常遊走在C與C++之間，最近則是因為改SublimeText plugin在學python XD 雖然不敢說是高手，但也看過一些open source的code busybox/dhcp, xbmc, openwrt framework, Qt ++operator對於字串操作是極其常見(其他暫不提) 所以我一直以為這是很稀鬆平常而且基礎的寫法 這是第一次遇到有人告知我這種寫法不准用，老實說有點難接受 我完全理解"不要為了語法的漂亮而使用少見難懂的語法" 我自己也常這樣告誡自己，可是"難懂"的分界到底在哪裡？ 同樣一句話由Google工程師或是學生說出來可以說是完完全全兩個世界 因為兩者對"難"的定義可說完全不一樣！ 另外再問一個： function pointer/function object也是怪物嗎？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.181.142.174 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1429939856.A.D00.html
推
04/25 14:12, , 1F
這種寫法的優點除了少一行程式之外，我想不到有其他優點..
04/25 14:12, 1F
→
04/25 14:13, , 2F
搬到下一行去++不好嗎?
04/25 14:13, 2F
推
04/25 14:15, , 3F
就是咩，幹嘛搞複雜，
04/25 14:15, 3F
→
04/25 14:30, , 4F
所以大家都不用c libraray裡的function 自己改用好理解又
04/25 14:30, 4F
→
04/25 14:31, , 5F
簡單的實作?
04/25 14:31, 5F
推
04/25 15:08, , 6F
寫Code跟寫文章一樣是給人看的啊，能夠好好理解，不容出
04/25 15:08, 6F
→
04/25 15:08, , 7F
錯是很重要的。沒錯，文言文有精深的學問，現在沒人用
04/25 15:08, 7F
→
04/25 15:08, , 8F
文言文聊天吧。
04/25 15:08, 8F
推
04/25 15:10, , 9F
Function point很少場合用，比如在我開發自家script eng
04/25 15:10, 9F
→
04/25 15:10, , 10F
ine時使用
04/25 15:10, 10F
→
04/25 15:18, , 11F
++這種大一就應該懂的水題 有什麼難看懂的
04/25 15:18, 11F
→
04/25 15:18, , 12F
不如把++刪掉 都用i=i+1好了 超簡單
04/25 15:18, 12F
推
04/25 15:39, , 13F
難懂是看不懂的說的，但你無法讓每個人好懂。最簡單的
04/25 15:39, 13F
→
04/25 15:39, , 14F
方法就是讓別人看不到，比如library或api,僅外露讓人容
04/25 15:39, 14F
→
04/25 15:39, , 15F
易使用和呼叫的介面。
04/25 15:39, 15F
推
04/25 15:42, , 16F
基本市我給自己寫程式的終極目標，是讓初學程式的學生都能
04/25 15:42, 16F
→
04/25 15:43, , 17F
看了之後略知一二，但又不犧牲效能以及架構的需求
04/25 15:43, 17F
→
04/25 15:44, , 18F
當然這每個人都不同，但如果有人跟我抱怨++寫法難懂，我會
04/25 15:44, 18F
→
04/25 15:44, , 19F
改用更簡單的寫法
04/25 15:44, 19F
→
04/25 15:51, , 20F
除非你永遠都要單打獨鬥，不然team work就是要遷就伙伴
04/25 15:51, 20F
→
04/25 15:53, , 21F
要嘛就花力氣把你的伙伴都教到和你一樣smart
04/25 15:53, 21F
→
04/25 15:54, , 22F
要不一開始就寫那種不用教，也能讓人一眼完全理解的code
04/25 15:54, 22F
→
04/25 15:55, , 23F
你覺得哪個比較費力？
04/25 15:55, 23F
推
04/25 16:09, , 24F
說真的你懂原理就用，不懂就不要用啊！
04/25 16:09, 24F
→
04/25 16:10, , 25F
事實上你的狀況是看了ㄧ堆專案其實你跟本就不懂....
04/25 16:10, 25F
→
04/25 16:11, , 26F
然後在這到處質疑人...
04/25 16:11, 26F
→
04/25 16:18, , 27F
請問我不懂什麼？ 我也從沒說我什麼都懂啊？ 本來每個人
04/25 16:18, 27F
→
04/25 16:18, , 28F
就有懂或不懂的東西 但是因為不懂就不准用才是我質疑的點
04/25 16:18, 28F
→
04/25 16:20, , 29F
今天假設真的是業界標準是這樣 讓新鮮人知道一下有壞處嗎
04/25 16:20, 29F
→
04/25 16:25, , 30F
如果因為不懂繼承或組合 就要求擴充的時候只准寫全新的
04/25 16:25, 30F
→
04/25 16:26, , 31F
這樣真的有人可以接受嗎？
04/25 16:26, 31F
→
04/25 16:34, , 32F
不知道原po有沒看過clean code. 到底怎樣算難懂，怎樣可
04/25 16:34, 32F
→
04/25 16:34, , 33F
讀性算不好。書上有提供一些經驗跟理由。雖然我只認同80
04/25 16:34, 33F
→
04/25 16:34, , 34F
%但我覺得啟發蠻多的。
04/25 16:34, 34F
→
04/25 16:35, , 35F
a = i++; 改寫成 i++; a=i; 其實沒有很難..
04/25 16:35, 35F
推
04/25 16:37, , 36F
樓上好像寫反了吧..
04/25 16:37, 36F
→
04/25 16:37, , 37F
樓上的兩個寫法a是不一樣的喔
04/25 16:37, 37F
推
04/25 16:38, , 38F
XD..
04/25 16:38, 38F
→
04/25 16:38, , 39F
@Masakiad 所以glibc那個code算是閱讀性不好的嗎？
04/25 16:38, 39F
還有 34 則推文
→
04/25 18:08, , 74F
行為都規範的很清楚，user通常不需要看他的實做
04/25 18:08, 74F
→
04/25 18:09, , 75F
可是standard lib沒有維護的需要嗎？ 他不是很多人協同合
04/25 18:09, 75F
→
04/25 18:10, , 76F
合作而出來的產物 我之所以舉一些大型open source或是商業
04/25 18:10, 76F
→
04/25 18:11, , 77F
作為例子 就是認為它符合各位所提的 "有維護需求", "多人
04/25 18:11, 77F
→
04/25 18:12, , 78F
人開發"的前提 比起有些書可能著重個人觀點來得有討論基準
04/25 18:12, 78F
→
04/25 18:14, , 79F
我在想會不會太拘泥於++這個例子阿? 這個例子很難感受阿
04/25 18:14, 79F
→
04/25 18:15, , 80F
都有維護需求啦 當一個人長期看同一份code 都能看懂 但
04/25 18:15, 80F
→
04/25 18:15, , 81F
是很多人都有那種很痛苦trace code的經驗吧 我想你就用
04/25 18:15, 81F
→
04/25 18:16, , 82F
就盡量去寫++好了
04/25 18:16, 82F
→
04/25 18:17, , 83F
很多人的痛苦來自於要trace很多份不同人寫的不同領域產品
04/25 18:17, 83F
→
04/25 18:17, , 84F
又沒有三個月給你去仔細研究
04/25 18:17, 84F
→
04/25 18:19, , 85F
或許你可以試著去trace STL的code看看...一個禮拜...
04/25 18:19, 85F
→
04/25 18:19, , 86F
這個每個人工作都需要啊 應該沒有人不需要的
04/25 18:19, 86F
→
04/25 18:20, , 87F
開新project的時候不是就是拿不同team不同人的code portin
04/25 18:20, 87F
→
04/25 18:20, , 88F
至於書說是著重個人觀點 我是部份不同意 其實有些書的觀
04/25 18:20, 88F
→
04/25 18:21, , 89F
g + integration XD?
04/25 18:21, 89F
→
04/25 18:21, , 90F
點反而是收集眾多的案例 話說回來 還是要自己多想多體會
04/25 18:21, 90F
→
04/25 18:22, , 91F
我是說“可能”是個人觀點
04/25 18:22, 91F
→
04/25 18:22, , 92F
我不是反對你的論點 我只是說明書其實也是收集案例的
04/25 18:22, 92F
→
04/25 18:23, , 93F
所以你拿到的code都輕鬆trace? 可以trace看看ACE阿?
04/25 18:23, 93F
→
04/25 18:24, , 94F
trace MFC跟gtk framework....
04/25 18:24, 94F
→
04/25 18:25, , 95F
沒有啦 反正各自提觀點 若是大大的經驗都很輕鬆愉快 真的
04/25 18:25, 95F
→
04/25 18:25, , 96F
神手是沒有在怕什麼寫法的 yoco大大已經如此開釋過了
04/25 18:25, 96F
→
04/25 18:25, , 97F
end!
04/25 18:25, 97F
→
04/25 18:30, , 98F
我沒說trace code很輕鬆 但是不會因為++而覺得難懂
04/25 18:30, 98F
→
04/25 18:30, , 99F
而且語法很難懂 跟這段code想要幹什麼很難懂是兩件事
04/25 18:30, 99F
→
04/25 18:31, , 100F
就說太拘泥++這個例子了 可能沒理解其他大大說的精神....
04/25 18:31, 100F
→
04/25 18:32, , 101F
不是拘泥++ 只是用他當例子 光是macro又可以開另篇文
04/25 18:32, 101F
→
04/25 18:33, , 102F
我同意閱讀性這件事 我自己也經常為此改換寫法
04/25 18:33, 102F
→
04/25 18:33, , 103F
痾..................ㄏㄏ 拉拉 魯魯........
04/25 18:33, 103F
→
04/25 18:34, , 104F
其他版友提的我也了解
04/25 18:34, 104F
→
04/25 18:36, , 105F
就好像 (a > min && a < max) 我會直接定義成叫做RANGE的
04/25 18:36, 105F
→
04/25 18:37, , 106F
macro 我並不是不了解可讀性的重要 我也不是寫code沒給人
04/25 18:37, 106F
→
04/25 18:37, , 107F
review過 前公司也有使用review系統 通常同事都會提些意見
04/25 18:37, 107F
→
04/25 18:38, , 108F
可是從沒聽過有人反映某些基礎語法很難看不懂 所以不要用
04/25 18:38, 108F
推
04/25 19:22, , 109F
想要用類似 c 的語法，又不希望有 ++ expression 用法
04/25 19:22, 109F
→
04/25 19:22, , 110F
的話其實可以學 Go - https://golang.org
04/25 19:22, 110F
→
04/25 19:23, , 111F
不過其實也有連 ++ statement 都沒有的語言 0.0
04/25 19:23, 111F
推
04/26 22:02, , 112F
我支持這種寫法，有更簡捷的方法又不難，為何不用
04/26 22:02, 112F
→
04/26 22:03, , 113F
open source很多都這樣寫阿
04/26 22:03, 113F
‣ 更多 ah7675 的文章
文章代碼(AID): #1LEoQGq0 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 4 之 6 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共6篇)
‣ 更多 ah7675 的文章
文章代碼(AID): #1LEoQGq0 (Soft_Job)