删帖吧

幻の上帝

回复  幻の上帝

这种自由并不影响功能。_z 是规范， z_ 一样可以成为规范。
当然现在说这个话就 ...
OwnWaterloo 发表于 2011-10-13 17:37

代码实现的功能是不影响，但是毫无疑问会增加含有 z_ 的代码维护的工作量——如果这些旧的代码有必要符合新的规范的话。

OwnWaterloo

回复 61# 幻の上帝

"标准应该直接保留 _?" 只是假设如果C/C++标准还没有制定，我觉得这样会更简单。
对现有的标准我就不会提"加强限制，保留 _z"要求了…… 已经这样了，认了吧……

OwnWaterloo

回复 59# 幻の上帝

能问清楚当然好。
可是如果对方是谁都不知道的情况……
又或者我懒…… 懒得讨价还价…… 给一个我能接受的底限，成就成，不成拉到……

是很消极…… 但稍微想想…… 如果问清楚了，事也不好办……
项目A，要求用某编译器，得考虑该编译器能较好支持些什么。
项目B，要求用另一款编译器，得考虑该编译器又能较好支持什么。
做个类比： 将C++换成js,as什么的，将编译器换成浏览器…… 就是另一潭浑水……
若心里想着：这个项目是为IE开发的，我可以用什么，不可以用什么；那个项目是为FF开发的，我又(不)可以用什么……
也挺吃力的……


>> 其实“完美”的编译器至少要等多久，基本上都心中有数了。
你觉得会等多久呢？
没怎么关注C++11 以及各种编译器实现情况……
对gcc4.5+的动力其实还不是来自C++11， 而是来自link time optimization…… 于是发现认识的人没有用4.5+的……
也懒得自己弄一个………………


还是说这是反语？ 永远等不到？
gcc(4.4.0)到现在都还没修复 __cplusplus 的值的bug……………… 要修复其实是多简单的事情……
反正软件有点bug也不是什么稀奇事了……

OwnWaterloo

回复 59# 幻の上帝

>> 想规定出所有细节并让程序员依赖这些细节会让双方终止陷入泥潭

这是因为最近稍微看了看 ecmascript 再一次获得类似感悟。

比如这： http://ecma262-5.com/ELS5_HTML.htm#Section_15.4.4.14
虽然ecmascript是动态类型检查而且还是弱类型，规则可能会更复杂一些，但这是在闹哪样……
是拼音还是识数教学呢？
都弄到这程度ecma也别搞什么规范了，再努力一把将这写成实际代码世界也许就清净了……

对比ISO C++中库提供的算法描述，顿时优越感油然而生……

chinesedragon

应该是思想

幻の上帝

回复  幻の上帝

"标准应该直接保留 _?" 只是假设如果C/C++标准还没有制定，我觉得这样会更简单。
对现 ...
OwnWaterloo 发表于 2011-10-14 02:58

    嗯，认了。

幻の上帝

回复 63# OwnWaterloo

设法在问清楚的一刻起即自我限制。……避免之后突然想到不能用什么才改手忙脚乱的改代码。
消极的办法可以尽量使“我可以用什么”之间的区别小一些，即使有，其中一种可以是另外一种的子集。这样可能比较不容易出错一些。

“完美”的编译器嘛……看哪种“完美”了。不全是反语。
最广泛意义上地说，我不指望出现任何“完美”的软件。
要是完成度像现在的编译器对C++03支持的那样，少说三五年吧。
但如果只是适合自己要用的特性子集，“完美”的标准是没bug，生成代码足够符合需要的话，可能现在就有。

现在更新编译器release也像日常更新普通应用软件一样，习惯了；倒不是特意想要用什么新特性（往往越是这么想越容易损害代码可移植性）。gcc4.6之前我也绝少使用C++11特性（也就偶尔VC10上用用lambda，以及type_traits的tr1子集）。现在gcc的一些主要C++11特性组合起来已经可以日常使用了，VC11以及其它编译器总体上还差一些。

__cplusplus的那个试了一下，4.7正常。
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
2001年的bug拖到现在才fix……嘛，无语= =

幻の上帝

回复  幻の上帝

>> 想规定出所有细节并让程序员依赖这些细节会让双方终止陷入泥潭

这是因为最近稍微 ...
OwnWaterloo 发表于 2011-10-14 03:29

给出完整详细的操作语义描述，相当于半个实现了……感觉倒不如直接给个参考实现= =。