[請益] 這是什麼語法 (for C)?

作者: wsad50232 (阿豐)   2022-05-14 13:52:08
*ptr++ =
"zyxwvutsrqponmlkjihgfedcba9876543210123456789abcdefghijklmnopqrstuvwxyz" [35
+ (tmp_value - value * base)];
在這邊看到的
https://stackoverflow.com/questions/8257714/how-to-convert-an-int-to-string-in-c
不怕各位笑,小弟摸C語言這麼久,今天第一次看到這種寫法
看了半天,實在是不知道是什麼意思
程式碼我Compile過,確定是可以編譯可以Run的
有高手能給個解答嗎?
作者: NDark (溺於黑暗)   2022-05-14 13:58:00
應該是指定某一已知記憶體的數值具體來說要看那塊記憶體有什麼特殊
作者: DarkIllusion (′・ω・‵)   2022-05-14 14:00:00
抱歉 我不太懂你對哪個部分不懂?
作者: OyodoKai (魔法少女大淀)   2022-05-14 14:00:00
哪裡看不懂?
作者: ccpz (OoOoOo)   2022-05-14 14:02:00
=右邊的部分,是把字串當陣列,去抓出某個 char 而已
作者: TheOneisNEO (Thomas Anderson)   2022-05-14 14:16:00
就排排站然後取index吧 你把那一長串字串先assign給另外一個變數也可以
作者: NDark (溺於黑暗)   2022-05-14 16:53:00
基本上賣弄技巧的程式碼都是軟體工程的大敵在我手下 有人敢這樣寫 我一定背後記住
作者: TwitchGod (妹子打LOL臭了嗎=3=)   2022-05-14 17:02:00
看不懂這該回去重修大一程設吧
作者: Belieeve (芥末拿鐵)   2022-05-14 17:23:00
看來是道行高深的忍者呢
作者: wulouise (在線上!=在電腦前)   2022-05-14 17:24:00
不會看不懂 可是code review不被電很奇怪
作者: steve1012 (steve)   2022-05-14 17:43:00
這根本過不了code review
作者: calqlus (白夢の繭)   2022-05-14 17:44:00
阿就atoi的封裝寫法平常會用查內建函式就很不錯了
作者: ManOfSteel (Man Of Steel)   2022-05-14 18:54:00
不會看不懂,但是看這個心情會很差...
作者: ssccg (23)   2022-05-14 19:05:00
轉換用先建好的表 + 算index查表算是很平常的做法吧?單純抓這一行來看才會一時看不懂,原本的函式很好懂啊覺得這篇的問法有點斷章取義
作者: Gaogaigar   2022-05-14 20:36:00
前面註解寫個LUT 我review 會給過
作者: jayd   2022-05-14 20:54:00
這種寫法code review絕對被靠北
作者: shadow0326 (非議)   2022-05-14 22:50:00
這不是賣弄,而是偷懶吧
作者: shownlin (哈哈阿喔)   2022-05-15 01:38:00
這個用法覺得還算正常...最近在碰device tree compiler裡面的checker也是這樣建表的大家review的規則比大神還嚴欸0.0
作者: CoNsTaR ((const *))   2022-05-15 02:52:00
很多人對爛 code 的定義就是只要我看不懂就是爛 codecode smell 的定義就是只要不合我的意就是 code smell結果自己寫出來的反而笑死人
作者: wei115 (ㄎㄎ)   2022-05-15 02:56:00
還好吧 就把字串當陣列用阿 其實我覺得*ptr++還要想一下(x
作者: netburst (133 134 592)   2022-05-15 03:31:00
作者: sunsamy   2022-05-15 04:01:00
也許人家是刷題仔,刷題很多這種賣弄技巧的寫法,解法
作者: OnlyRD (里巷人)   2022-05-15 09:11:00
c型別系統和指針不熟才會看不懂吧?另外說review不會過,大部分應該都是在做上層應用的人,原程式是為了解決itoa並不在c標準的問題,因此才產生這份code,當然對於效能和記憶體的要求就遠高於易讀,畢竟各位上層高手幾個人會去看c標準庫的實作?toolchain自帶標準庫通常也都只有程式庫和標頭檔而已。但這類缺乏易讀性很像在玩技巧的實作方法,越底層的庫越多,都是有它的理由的,又不是吃飽閒著。而且這段code對寫c的人很基本吧?看不懂的人你才要擔心他會不會製造許多型別轉換和指標操作的詭異bug。
作者: shooter555 (shooter)   2022-05-15 09:16:00
很少看到不先把常數字串先定義好再用的寫法給個變數名 後人還能知道這串是什麼碗糕
作者: sanctitysky (常自在)   2022-05-15 09:18:00
對c來說 很清楚常見
作者: yupog2003 (屁股)   2022-05-15 09:34:00
推OnlyRD,易讀性和效能有時候沒辦法兼顧,看需求而已
作者: sazabijiang (筆落驚風雨詩成泣鬼神)   2022-05-15 11:45:00
這就是為什麼會有Java的誕生
作者: Bencrie   2022-05-15 12:34:00
有標準的 snprintf 要這個幹嘛?
作者: wulouise (在線上!=在電腦前)   2022-05-15 14:12:00
底層library跟上層應用的review標準不同,我是以上層看
作者: labbat (labbat)   2022-05-15 14:15:00
去跟主管講唄,說服網友幹嘛
作者: wulouise (在線上!=在電腦前)   2022-05-15 14:19:00
@Bencrie 見https://bit.ly/3LdC6LV 它比snprintf快
作者: sazabijiang (筆落驚風雨詩成泣鬼神)   2022-05-15 14:22:00
一個後人無法容易維護的程式碼,就是爛的程式碼
作者: bnd0327 (阿噗噗)   2022-05-15 16:21:00
這行就是沒有要讓人維護的,這是基礎函式,不是商業邏輯
作者: sazabijiang (筆落驚風雨詩成泣鬼神)   2022-05-15 16:32:00
然後會出錯的地方,就是這種沒打算讓人維護的地方
作者: brucetu (sec)   2022-05-15 17:57:00
寫底層的跟寫商業邏輯的在討論可讀性目的就不同 作法當然不同code review看到這段code出現在itoa的實作裡面還感覺不出是在做什麼操作的 是review的人有問題吧?review本來就要看整個context啊
作者: Bencrie   2022-05-15 18:50:00
不要可讀那不考慮直上 asm 嗎?
作者: Firstshadow (IamCatづミ'_'ミづ)   2022-05-15 19:16:00
這個很好讀吧 哪裡不好讀==
作者: shownlin (哈哈阿喔)   2022-05-15 19:47:00
kernel裡面不就一堆.s話說這一段code明明就很直白硬要扯說看不懂也太扯
作者: acgotaku (otaku)   2022-05-15 20:27:00
大家這麼兇 以後誰敢問問題但會這樣寫的,有點像是程式新手
作者: knme (knem)   2022-05-15 20:32:00
code review看到這個,會希望前面多個註解
作者: shownlin (哈哈阿喔)   2022-05-15 20:52:00
原來GCC底層是一群新手寫的嗎……
作者: wulouise (在線上!=在電腦前)   2022-05-15 21:08:00
本來code review就是根據維護人的能力來評估的實際上不會有這麼多人都有維護gcc底層的能力
作者: sarafciel (Cattuz)   2022-05-15 22:37:00
新手才不敢這樣寫啦 要看懂這段code會吃對指標的理解
作者: manmay (書誠)   2022-05-16 00:44:00
常數字串查表比額外宣告一個區域變數快很多吧
作者: hengsao (千金)   2022-05-16 04:57:00
一群能力不到的人對自己能力不到的程式庫該怎麼實作很有意見==
作者: shooter555 (shooter)   2022-05-16 09:34:00
不提前宣告這串char 而丟在loop裡面 不知道是什麼操作是我是不會這樣寫前面推文有提到理由 那這邊的理由不知道是什麼 有高手知道的嗎
作者: xxtuoo (浪費時間不好QQ)   2022-05-16 09:43:00
這幾行看不懂的 才該被注意Zzz
作者: ssccg (23)   2022-05-16 11:38:00
常數丟在loop裡還是常數,就只用在這為什麼要另外生個變數?
作者: freef1y3 ( )   2022-05-16 11:45:00
compiler沒這麼笨 你就算先生個變數存也不會比較慢啦..
作者: aasssdddd (路人庚)   2022-05-16 12:38:00
第一次看到 長姿勢了 不管寫法一定有地方特別存那字串
作者: ssccg (23)   2022-05-16 12:46:00
不是說快慢有差,是在回兩樓前的,為什麼要提前宣告?
作者: labbat (labbat)   2022-05-16 13:30:00
一大串人類看不懂啊,宣告就是逐步做一大串做的事情
作者: sarafciel (Cattuz)   2022-05-16 14:01:00
不會比較慢其實不好說XD 要看你變數型態怎麼給compiler不笨沒錯 但compiler會為了programmer變笨然後你知道函式是itoa的話,要理解那個字串的意圖不難在這個前提下,他這樣寫的用意我猜是scope就跟anonymous function的目的一樣,只在某處只用一次如果你把這個表拉出去迴圈外,作為reviewer第一時間看會假定這個字串在函式內有好幾個地方用到而他這樣寫相當於告訴你scope鎖死在這一行
作者: brucetu (sec)   2022-05-16 21:09:00
到底是*ptr++=真的沒那麼難懂字串查表也很常見很多爛程式可讀性差是因為物件之間的關係混亂 職權不清。看不懂這行的叫做語法不熟 不是他寫成一行可讀性差
作者: manmay (書誠)   2022-05-17 00:51:00
c語言標準有定義 常數字串的storage durationC99 $6.7.8 Initialization
作者: descent (「雄辯是銀,沉默是金」)   2022-05-17 17:58:00
c 博大精深, 真的有很多沒看過的用法。另外char no_name[72]="z.." 可能應該要改const char *no_name = "z..." 比較恰當
作者: oToToT (屁孩)   2022-05-17 18:16:00
上面那樣改的話no_name還是會被指去不同地方,可能還是不太好?
作者: descent (「雄辯是銀,沉默是金」)   2022-05-17 20:26:00
這問題也可以 po 到 c_cpp 版
作者: newking761 (J三小)   2022-05-18 08:34:00
如果我是你老闆,你大概離職了
作者: wsad50232 (阿豐)   2022-05-18 11:34:00
樓上可能不適合當老闆
作者: Isaea (Isaea)   2022-05-18 12:37:00
c最多這種把好幾行濃縮在一行的寫法,老實的拆開不好嗎
作者: sazabijiang (筆落驚風雨詩成泣鬼神)   2022-05-18 17:34:00
炫技
作者: eva19452002 (^^)   2022-05-20 17:59:00
寫個可讀性高的程式碼會犧牲很多效能嗎?
作者: OnlyRD (里巷人)   2022-05-21 15:49:00
compiler會把c string放到字串section,程式啟動後初始化,整段操作只是計算記憶體中的偏移量再去計算而已。以為c碼農應該都對compiler不陌生才對,因為c就是貼近底層的語言。整串看下來,好像不少人對語言標準、編譯器都沒啥掌握,避開底層工作吧。
作者: cia1099 (阿兜啊)   2022-05-21 20:32:00
不會到看不懂,只是要回想思考一下,這就會讓人憤怒
作者: wulouise (在線上!=在電腦前)   2022-05-21 20:51:00
歷史因素 就像++i i++現在幾乎沒差除非compiler很爛有些時候當時那樣寫效率最高 但是現在不這樣寫不一定差
作者: OnlyRD (里巷人)   2022-05-22 03:48:00
樓上,要看你的i是什麼type,c++會更複雜一點,而且在某些支援特殊指令的cpu上有差別。另外++i和i++的語意不同,怎麼會沒差?如果是c++,換成class和template再試試看就知道了。
作者: wulouise (在線上!=在電腦前)   2022-05-22 14:26:00
可能我省略太多,是單行的i++;跟++i;不是所有情況
作者: DoubleFree (蕭景琰你給我站住)   2022-05-24 10:30:00
看不懂就是爛code 我還滿同意的明明有更清楚的寫法幹嘛弄成跟大便一樣
作者: ohohohya (安安你好我草泥馬)   2022-06-04 05:59:00
基本上你待在公司就寫符合公司coding style的code就好了 這段老實講沒到會被reviewer打槍的程度 大意也只是從字串中間開始計算要拿哪個index字元的ascii加回*ptr的內容而已

Links booklink

Contact Us: admin [ a t ] ucptt.com