[kde-china] c 语言字符串...

[panshizhu在routon.com]

其实 C 语言并没有强制这么做，绝大多数 C 字符串函数都包含按零结尾处理和按指
定长度处理的两种版本。
例如：
strcpy vs strncpy
strcmp vs. strncmp
等等。
因此，即使你使用 C 语言，也完全可以使用一个独立的整数标记字符串长度，然后对
于所有的字符串操作使用带 n 的字符串函数。――显然，直接在 C 语言中这么做，编
程上会比使用零结尾稍微麻烦一些，但如果你使用适当的包装可以规避这些问题。不
要忘了pascal 使用单字节标记导致字符串最大长度 255 的限制，它只运用于教
学，而这种限制对一个实用的语言来说显然是不可接受的。

事实上我不知道你真的使用任何 profiler 工具测量过没有，实际对于 C 语言字符
串，多数普通情况下两者的效率差距并不大，对实际运行效率的测量很多时候会让人
怀疑自己所学的知识。――也许因为某些理论家从来不做测量。

当然xml是个把这种差距运用到极致的例子，不过谁又能规避这个问题呢？对于任何脚
本语言的解析都不可能避免字符串搜索以获取结束符的问题，这并不独是xml的，文法
解析效率应当是所有解释型脚本存在的问题。
--
Sincerely, Pan, Shi Zhu.

yarco <yarco.w在gmail.com> 写于 2008-11-28 20:49:50:
> 恩恩......不过我说的的确是执行效率......
>
> 我买过一本叫"Joey说软件"书. 那里开篇提到的那个文章很经典, 从c语言字符
> 串一直谈到为什么xml执行效率不高.
> 好像原因是因为c语言字符串是根据\0来计算结束符的. 这样在很多过程中要判
> 断一个字符串就要从头到尾遍历到\0.
> 而delphi(好像是delphi)字符串是把那个\0 1byte让出来,  用来存放长度(所
> 以delphi字符串长度只能到256.
> 再长就得用StringBuilder)...xml有相似的情况,
> 因为只有结束标记<tag></tag>从程序角度就无法快速处理(假如是个length,
> 就能马上偏移定位)...
>
> 不过奇怪理由这么充分...到目前为止似乎也没看过什么变化...
> (据那本书说, excel开发的时候不使用c string, 而内部实现了一个字符串的
> 结构, 这样执行非常高效....)
>
>