删帖吧

幻の上帝

回复 39# OwnWaterloo

这是可能的，但即便如此，在任何情况下都考虑这点并不一定合理。
首先，得排除我在写一个标准库的直接或间接实现；
其次，如果我已经确信我能够完整地遵守规则，考虑这样的命名纯粹是兼容性问题了。
造成_z使用上会产生问题的原因可能有以下几类：
实在太旧（乃至早于ANSI C）的代码——受legacy code之类或许是C之前就有的传统了，一直延续至今；
和你说的类似，库的作者不熟悉完整的规则——比如库的作者在这方面是新手（但是语言实现在这方面不遵守，我觉得过分了些——除非作者明确的认知到已经放弃了ISO C++兼容性）；
有意的使用（例如，要实现一个类似M$的_T的玩意儿，又担心违反规则，于是用了_t——只是举例，实际上应该不太可能这样用），但没有足够详细的文档。
这些原因都并非不能容忍，所以只是为了简便，避免使用_开头的标识符是可行的。不过，这里的解决方法并不是很难，针对宏名的问题使用workaround维护兼容性相对来说是比较容易的（尽管看起来可能会比较累），同样是可行的。
但是，对于正式的代码，习惯上我使用后者（会比较折腾我认了……）。原因是这些规则是明确的、普适的、显式的和相对稳定的约定，比起某个具体的库来说能在更广的范围被接受。尊重这些规则的实践应当是普遍适用的。
突然觉得有点像VC6被人骂的原因很大一部分不是编译器自身质量的关系一样……（然而考虑年代，这里倒不都是VC6的不对）= =
附较完整的规则参考：
http://stackoverflow.com/questio ... e-in-a-c-identifier

AD8018

回复  OwnWaterloo

附较完整的规则参考：
http://stackoverflow.com/questio ... e-in-a-c-identifier
幻の上帝 发表于 2011-10-13 09:30

    Thank you, 收藏学习

OwnWaterloo

回复 41# 幻の上帝

没看明白对 _z 是什么态度……

说说我对该问题的一些考量吧：

1. 这规则确实太复杂(或者说生僻?)
2. 连我自己都没把握能100%弄明白，自然也就不会相信 —— 不说100%吧 —— 能有一半以上的人能弄明白这个规则
3. 也是最重要的一点
写作 z_ 不会带来什么坏处，至少风险比 _z 要小得多。 那么我干嘛要去冒这个险？
要是哪天真被某个黑心编译器给阴了，得花多少时间才能明白是因为这个？

各种C/C++编译器的各种版本各种编译选项之间的兼容性是把我整伤心过了的。惹不起我躲还不行吗？
写作 z_ 对我来说并不是什么大不了的事情 —— 我对编程风格、命名规范什么的没什么强迫症 —— 倒是可以懒得去操心这一堆事。

幻の上帝

回复  幻の上帝

没看明白对 _z 是什么态度……

说说我对该问题的一些考量吧：

1. 这规则确实太复 ...
OwnWaterloo 发表于 2011-10-13 10:18

重点不是对 _z 的态度，是整体的观念以及可操作的方法。
1.不算太复杂。如果不看资料要罗列全是有难度，但日常用起来不复杂。
不用 _z 只用 z_ 是一种的可行的做法，但至少对我而言是 premature optimization ，考虑得像是不必要地简单了。
我的做法：
1.1 任何时候不连用下划线，除非我在实现标准库（下同）。
1.1 了解 _z 没有被正式的规则在所有场合下禁止。
1.2 纯C要更小心一点，因为没有namespace（或者等同于C++的只用global namespace的情形）。这时候不使用任何 _ 开头的标识符。
1.3 不使用 _ +大写字母的标识符。
1.4 考虑避免使用其它前缀和后缀（SIG/LC/_t什么的）。
其实关于下划线也就是 1.1 、 1.2 和 1.3 三条。这里讨论的关于前缀下划线 1.2 和 1.3 两条。这不复杂。
PS.还有不得不使用下划线的：C++11 17.6.4.3.5 “Literal suffix identifiers that do not start with an underscore are reserved for future standardization.”
2.我可以选择向不明白的人解释。这些解释是可以重用的。
3.的确，对你写的东西而言是没有什么显见的坏处。
但是规则的存在不是为了去逃避的。这样的代码同时可以用来检验语言实现和配套的库的质量。
当然我不是说要无谓的冒险，为了做成样板故意去使用 _z 。即便是愿意冒险，也应该尽量选择风险较小的情形——因为期待成功。
我对命名风格之类也没什么强迫症，只要保持相对一致不要让人觉得故意让读者看不顺眼就行。
不过，如果不是有不得不让步于兼容性的现实需要（这点对于我个人而言是罕见的——或许是我用过编译器和选项组合不多的关系；如果我给别人写代码则会优先考虑对方的意见，有没有convention之类），我乐于看到我的代码预先炒掉不怎么符合规范的实现（这里的东西对一个语言实现而言其实是很容易遵守的，如果这都能出问题嘛……），以免给自己提供借口结果让后续维护时追加的workaround无法收场。这种做法也许对你而言是 premature optimization ，不过对我而言则不是，因为遵守规范没使我觉得浪费额外的精力，即使我刻意不用 _z 这样的写法，排除不得不需要某种兼容性的情形时，除了纵容一些不符合规范的代码或实现以外，没什么“好处”。（向别人解释或许是得花点脑细胞，不过既然是有出处的明确的约定，成本不会太大，在2.也已经提到了——当然，我指望别人会去理解某些东西的权威性，这点或许并不值得提倡。）

OwnWaterloo

回复 44# 幻の上帝

向别人解释这点我就觉得不靠谱了……
有功夫为了这个问题而解释，我还不如多解释解释，呃，比如就拿新鲜的例子来说，const取址会产生什么不好的影响 —— 我觉得要更有价值一点。


"逃避"这个词我觉得用得不恰当。
避免 _z 也是在遵守规范，我没说错吧？ （先不考虑 C++11 那条…… ）
并不一定是"规范说可以用什么，我就用什么"才算遵守规范。
规范说可以用什么，但我就不用，而且并不影响我编程 —— 使用一个满足自己需要的更小的有更多限制的集合 —— 这也算遵守规范。

而且我不认为C/C++对此规范制定是合理的。
C以及C++已经够复杂了。
如果当初就干脆更限制一点，统一一句 _z, _X 都是我的，你们别用。会对C/C++用户造成影响吗？ 不会，而且标准文本会更简单。
可以避免人们（程序员以及编译器开发者）为这种并不是很重要的事情过多的消耗脑力。

即使是以简单著称的C语言，也有这样那样的多余的东西。
就好比每次我给人解释条件包含。
如果先说 #ifdef/#ifndef 吧， 迟早需要解释 defined 。
但如果先解释 defined ， 高达八成会被问： 哪为啥还需要 #ifdef/#ifndef ？ 就为了少敲几个字么？

这里面有可能有历史因素。
规范即使我认为不恰当，也已经是这样了 —— 但我依然还是用一种自我阉割的方式在遵守……


less is more，可惜很多人都不明白，明白人也不一定能贯彻这道理……

OwnWaterloo

回复 44# 幻の上帝

>> 2.我可以选择向不明白的人解释。这些解释是可以重用的。
重用也至少得发个链接吧……
而且，对方要听得进去才行啊！
以珍惜对方脑容量的名义，我宁愿解释一些更有价值（比如缺少了可能就没法编程的）的东西。


>> 即使我刻意不用 _z 这样的写法，排除不得不需要某种兼容性的情形时，除了纵容一些不符合规范的代码或实现以外，没什么“好处”。
关于这种做法会纵容不合符规范的代码这点我绝对同意。
现在的问题是我不认为这规范是合理的……  理由上面有说。
所以……  让这种不符合规范的代码来得更多吧…… 然后将这个限制标准化就太平了……  我…… 邪恶了……


关于权威。
我对权威也没什么特别感觉。
即使是BS、 lippman、 meyer、 Sutter， 我都只是认为相比其他人，他们的观点我赞同的更多而已。
并不是他们说什么我就真要那么做。


ISO C++是死的。符合ISO C++的代码：
1. 没有编译器支持
2. 或者一些支持另一些不支持
3. 或者一些不支持、 一些以某种(不)符合ISO C++的方式支持、 一些以另一种(不)符合ISO C++的方式支持
4. ……

我很久都不怎么写C++了，没法即时想出例子。
但这样的情况绝对是太多太多了， 尤其是与模板相关的时候。

遇见这些问题时怎么办？ 总不能代码写在那里摆着说：我等完美支持ISO C++的编译器出现。 吧？
即使出现了， 也要有人用这编译器才行啊。


_z 没遇见问题是因为我没这么写过。也许如你所说那样是一种 premature optimization。
但可能Sutter是真遇见过这样的问题。


我研究ISO C/C++的主要目的是写出更好的程序，准确说是对平台依赖性更小的程序。
通过 ISO C/C++ 了解一些诸如： 那些行为仅仅是我所在平台才有的， 那些是ISO C/C++规定的。
在那些规定了的行为当中， 那些是较为可靠的， 那些是不那么可靠的。
不太可靠的东西，只要不影响我实现功能，我就干脆不用；如果影响实现功能了，就谨慎的在小范围内使用。
这么避让着避让着……
不单单是 _z 不用了， 在不能控制编译器的情况下干脆C++也不用了……

goldenfort

回复 1# xyfree


    其实是一回事情，  不过叫一个人 高手 他就牛 B起来，叫它程序员  他就撅起嘴来

OwnWaterloo

回复 44# 幻の上帝

最后，关于C++11 ……
>> PS.还有不得不使用下划线的：C++11 17.6.4.3.5 “Literal suffix identifiers that do not start with an underscore are reserved for future standardization.”

我自己想了想（差点被绕晕了……）
1. 这似乎与 "T::_v" 没什么关系？
我是更倾向于都用 z_ 的形式， 当代码移植为C++11时不会造成影响吧？

2. 既然 literal suffix 必须是 _z 的形式
当写C++11 时就这么用咯， 反正也不打算向下与C++03, C兼容。

你的意思是为了"向C++11移植得更顺畅"， 所以现在就要让那些编译器作者意识到"不要用 _z 作宏名"， 所以要用 "T::_v" 的名字去检验这些编译器？

OwnWaterloo

回复 47# goldenfort

你能说出这样的见解我一点都不感到奇怪。

幻の上帝

回复  幻の上帝

向别人解释这点我就觉得不靠谱了……
有功夫为了这个问题而解释，我还不如多解释解释， ...
OwnWaterloo 发表于 2011-10-13 11:49

只是解释，仅限于给出依据和出处，以表明我的“不应该这样写”的观点和理由。没办法指望人家（脑袋没长我身上）一听解释就立刻明白……而且，人家愣要这么写，那我也没办法。对于先入为主的一少部分人不管解释与否对于解决问题都是没有用的，不过倒也不完全无用——退化成礼节上的形式了。
我说的逃避的宾语是规则（规范的条文），和遵守规范不矛盾。某个具体场合下避免 _z 当然不妨害遵守规范，但是在任何时候都应该不使用 _z 的主张就是故意避开规范了，虽然本意只是为了避开规范的陷阱。这样有意无意地架空了一些条文，是为逃避。
（那么，为什么标准要那么复杂呢？干脆规定 _z 不能用不就好了么……）确实，我同样不认为C/C++对此规范制定是合理的。
不过，我想这应该是妥协。
某一条哲学的大意是这样的：相信程序员，给用户尽可能的自由。既然现有实现没用到 _z ，干嘛要保留呢？这又有 premature optimization 的嫌疑了。
完全不保留更是不现实的，标准库实现用到的一些名称会造成不可避免的污染——宏名尚且能够#undef，但已经声明的函数和类型之类是无法被取消的——这是C/C++语言的限制。这种污染会损害程序的可移植性，原来合法的程序换个平台（标准库实现）就可能不合法了。并且，这样做会使标准版本更替时的负面影响更加不可控制。
于是就变成这样的半吊子条文了。不过它确实管用，具有可操作性。

虽然不甚优雅，不过#ifdef/#ifndef和#define能够完全互相代替么……

规范是这样了我也没办法，不过自我阉割就免了。。有些地方宁可 #ifdef __GNUC__ ...#...。不过这个问题没什么必要（当然写标准库的就会觉得苦逼坑爹了）。