[请益] 这是什么语法 (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