删帖吧

幻の上帝

回复  幻の上帝

>> 2.我可以选择向不明白的人解释。这些解释是可以重用的。
重用也至少得发个链接吧… ...
OwnWaterloo 发表于 2011-10-13 12:22

链接……41L底下的那个行么。
正因为不能保证对方一定会听得进去，我才说“指望别人会去理解某些东西的权威性，这点或许并不值得提倡”了。
不过，既然我只是提出一点潜在的问题，而并非把所有事都向对方灌输，是不是进一步花费脑容量取决于对方的个人意志，那我也没什么负罪感。

……这里的权威不是个人声望意义上的，是指行业中的各个有权威的个人组成的集体达成的妥协，并且其他人这种打破妥协需要付出不小的机会成本——比如，明确地不遵守ISO C/C++，可能就只限于特定编译器的特定选项能编译过你的代码了（除非能说服各大编译器厂商或者干脆向它们贡献代码，不过这就本末倒置了）——也就是说放弃了你的代码的兼容性，或者说你写的不能被公认为C/C++代码，只是一个不通用的方言的代码而已。

ISO C++的确是死的。不过死有死的好处。
通过查阅ISO C++，可以确定代码是否符合规范。一旦确定为符合ISO C++的代码：
1.很可能被支持（取决于标准已经通行了几年）；
2.极少数缺乏实践而几乎不被支持，乃至被deprecated（如export）；
3.许多现在不被支持（但未来可能被支持，前途是光明的= =……）。
为了确定1还是2还是3，可能需要翻阅文档。
不能确定为符合ISO C++的代码：
1.可能被支持；
2.可能不被支持；
3.在用户的印象中可能处于被支持或不被支持的叠加态。
为了使3退化到1或者2，你可能需要找其它的文档来确定它精确的行为，尤其是要考虑代码的兼容性时。
不能确定为符合ISO C++的代码的情形下，确定1还是2比前一种情况往往更复杂（搞不好Google关键字什么的都难想），许多情形下比一贯遵守ISO C++更费力——鉴于C++的自由和复杂，并不能指望任何东西都被良好定义的，甚至别指望都能找得到文档。

等完美支持ISO C++的编译器出现……吧，如果你有足够的耐心。
但是即便没有被完美支持，使用已经验证过的当前被较广泛支持的可用特性会很不方便么（export这类奇葩除外）。

_z 没遇见问题是因为我这么写过，不过真没遇见问题，并且我也归纳过什么时候真的会出问题——结论是，如果大家都遵守规范，不可能。好吧，这是理想情况，但这已经符合我遇见的情况了。如果我有更进一步的需求再放弃也不迟。

我研究ISO C/C++的主要目的是写出更好的程序，准确说是对ISO C/C++之外平台依赖性更小的程序。
尽管ISO C/C++不如JVM这么具体，但它们的每个版本事实上定义了一类平台，或者说environment+implementation。这类平台的内部边缘不清，因此实现有很大的自由。但是这类平台的公共界限是足够清楚的——what is a well-formed (ISO) C/C++ program。对于这类平台不兼容的依赖性通过严格遵守规范可以在理论上根本杜绝（内部的不兼容没办法，implementation-defined之类，算是C/C++的一大特色了）。或许这就是我的 premature optimization，但它对于我目前的需求而言，有效，且好用。
在精确控制实现的行为方面，C/C++这方面是一丘之貉，因为实现有太多的自由，且实现的数量不少。所以控制不了编译器的情况下顶多干脆C/C++都不用得了……= =

幻の上帝

回复  幻の上帝

最后，关于C++11 ……
>> PS.还有不得不使用下划线的：C++11 17.6.4.3.5 “Literal su ...
OwnWaterloo 发表于 2011-10-13 12:41

只是举例“不是什么时候都能避免 _z 的使用”。reserved for future standardization不是为了"向C++11移植得更顺畅"；以后它可以是reserved for implementation，或者规定更具体的语法。编译器作者在这里有最大的自由，不需要因此考虑“不要用 _z 作宏名”（实际上不能——这不是reserved name，普通用户可以自由使用，编译器或库占用了可能导致well-formed程序编译不过），倒是给普通用户打预防针。

Maxshine

回复 1# xyfree


    说点啥好，zhxxxxility?

OwnWaterloo

回复 50# 幻の上帝

好的……  确实算是逃避……

>> 某一条哲学的大意是这样的：相信程序员，给用户尽可能的自由。
这点也是无可厚非的，不这样就不是C/C++了。

但究竟要给予什么？哪种自由？
例如自由操作内存的能力。如果剥夺了这种自由，有些功能就无法完成。

但 _z / z_ 并不在这一类。
不允许用户使用 _z 并不会影响程序的功能， 甚至都不会增加敲字时间。

保留是肯定需要保留的，这个我理解。
我的意思是，如果当初干脆限制得更强烈一点 —— _? 全都保留 —— 既不影响语言的表达能力，而且好记！
更具有操作性不是么 —— 程序员/编译器实现者都痛快。
我敢说你给出的stackoverflow链接就只有几个（我都能点得出名来）的人会去仔细看。

至于条件包含， 将 #ifdef #ifndef 砍掉完全不影响条件包含的功能。
#ifdef/ #ifndef 只是少敲几个字而已， 连代码结构都不会改变。

用尽可能少的规则，完成相同的功能。
less is more.

OwnWaterloo

回复 51# 幻の上帝

关于权威的概念我理解可能有偏差。
而结论不变 —— 我依然认为这里规定不够好。

我也不会去刻意打破这里的规矩。也许没有 _z 的代码无法检测出不合规矩的C++实现，但总之这个规矩也不是由我打破的……


>> 为了使3退化到1或者2，你可能需要找其它的文档来确定它精确的行为，尤其是要考虑代码的兼容性时。
>> 许多情形下比一贯遵守ISO C++更费力
有些情况是， 但有些情况不是……
这个尺度我觉得自己还是能把握的……

比如 使用 z_ 而非 _z 就是这样一种情况， 我依然是在换一种方式遵守ISO C++。
不需要比使用 _z 查看更多的文档， 兼容性应该不会比 _z 更差。

再比如 —— C++的例子想不出来了，来个C的 —— extern inline 的行为。
c89没有inline， 但一般都有扩展。
c99有，但只有static inline的行为是确定的。
extern inline在gcc的不同版本里行为都不同…… 我了个去……
但是我不需要查询 gcc 3 与 gcc 4在这方面的详细文档， 我直接不用 extern inline 不就完了……
static inline 相对而言在各种编译器实现中更稳定， 我就用它好了……


>> 等完美支持ISO C++的编译器出现……吧，如果你有足够的耐心。
一个问题就是， 代码由谁编译？
我可能有耐心等到支持更好的编译器。
但代码不一定都是由我编译。
可能会有人想用更低版本的编译器来编译代码。

我觉得将自己的C++代码以源代码形式给予，要求对方有vc8以及gcc3以上比较合理。
而vc10,gcc4.5， 在我认识的人当中没有哪怕一个人有的……

C代码可以下降到vc6与gcc2……  所以需要发布的东西我喜欢用C……  连这俩编译器都没有的人，我真是有心无力了……

如果是写来自己用，那当然就可以用我想用的编译器了。
这是我说的"能控制编译器的意思"。


>> 但是即便没有被完美支持，使用已经验证过的当前被较广泛支持的可用特性会很不方便么（export这类奇葩除外）。
对了嘛…… 使用已经验证过的当前被广泛支持的可用特性， 你也知道有一些属于支持得不够好的。
我们没有质上的区别， 而是量上的区别。
只是我希望代码对编译器的要求更低一些， 使用的特性被支持得更广泛一些， 可用性更高一些。
当然，代码写起来会更痛苦一些……  自虐一些……


>> 在精确控制实现的行为方面，C/C++这方面是一丘之貉，因为实现有太多的自由，且实现的数量不少。
>> 所以控制不了编译器的情况下顶多干脆C/C++都不用得了……= =

想规定出所有细节并让程序员依赖这些细节会让双方终止陷入泥潭。
定义一组精简、但完善的规则 —— 标准的目的 —— 双方都尽可能遵守，这样双方才能得到发展，这才是正道。
less is more...

注意完善，总会有办法让你完成需要的功能，不至于完全不能用。
比如 signed 溢出的行为， 当不关心时就没问题； 当关心时语言有提供 unsigned 。
当不关心int长度时直接用， 当关心时用 intXX_t, int_fastXX_t 等等。

OwnWaterloo

回复 52# 幻の上帝

reserved for future standardization/reserved for implementation 这些道理我还是懂的。
既然C+11 要求 literal suffix 使用 _z 的名字，如上所说，我也肯定不会去打破这个规矩的。
我说的都是这个条件之外的情况……

我想弄明白的是你提到 C++11 这个条款的目的 —— 已经达到了
>> 只是举例“不是什么时候都能避免 _z 的使用”

我误会成 ……
1. 应该使用 T::_v 这样的名字
2. 检测出那些使用了 _z 作为宏名的C++实现
其实我们就是在讨论对某个编译器作者失误用 _z 作宏名这种情况该如何处理，对吧？
3. 促进这些实现得到改进
4. 为迎接 C++11 literal suffix 作好准备

幻の上帝

回复  幻の上帝

好的……  确实算是逃避……

>> 某一条哲学的大意是这样的：相信程序员，给用户尽可 ...
OwnWaterloo 发表于 2011-10-13 16:07

naming 的自由。规模一大，命名很容易成为维护代码中一件头痛的事。虽然并不是每个用户都关心，但是可能出现这种 naming convention ：约定 _z 和 z_ 表达略有不同的意思。
现在看来已经是历史问题了。大概当初标准委员会认为reserved identifier的集合越小越好。时间越长，legacy code越多，新增的规则breaking existed code就越容易，就越不适合加强约束。“好记”在C89之前或许是不错的想法，现在想要作为说服标准委员会的修改的动机怕是不够了。

OwnWaterloo

回复 57# 幻の上帝

这种自由并不影响功能。_z 是规范， z_ 一样可以成为规范。
当然现在说这个话就晚了， 一直都是在假设当初设定这个规矩的时候如果如果…… 怎样怎样……


删除线部分是我的错误。我把那句话看错了……
如果将 _z 保留， 还是可以用其他前缀或者后缀来表达 _z 的意思， 还是不影响功能。

幻の上帝

回复  幻の上帝

关于权威的概念我理解可能有偏差。
而结论不变 —— 我依然认为这里规定不够好。

我 ...
OwnWaterloo 发表于 2011-10-13 16:41

其实“完美”的编译器至少要等多久，基本上都心中有数了。一直以来的事实是，使用C/C++需要做好不得不面对语言实现而非语言自身的不完善的准备。
限制使用语言特性虽然消极，但是有效的，有时候是唯一的办法（workaround搞不出来……= =）。
给别人的代码，我倾向于事先向对方问清楚所有可能涉及的平台/语言实现。如果不指定，我同意你说的版本下限。
没有质上的区别， 而是量上的区别+1。
剩下的要说的基本被你说完了orz……
特别同意extern inline以及想规定出所有细节并让程序员依赖这些细节会让双方终止陷入泥潭。

幻の上帝

回复 56# OwnWaterloo

虽然本来不是讨论编译器作者失误的问题，不过要是这种失误出现了，按ISO C++它就是bug，patch吧。以实际效果来看手动#undef也不是不可以（虽然这个行为本身违反了关于标准库的约束，也是ill-formed的）。当然要是弄成关键字了就!@#$%……