奶奶的靠语言机制保证安全

walleeee

回复 90# 幻の上帝


>>int x[], int[] x
这个只是个人喜好，我觉得并不是什么大问题，前面一种侧重说明x的元素都是int类型，而后面一种侧重说明x是一个int[]的类型。一个强调元素，一个强调变量本身。但是它们的功能在编译层面来说都是等价的，不知道你同意不？

>>int, signed, short....
这个是没办法的，要看当时的机器工艺，cpu对处理这些数据使用了不同的指令支持，另外，这些数据类型不同，在cpu级别上的效率也有很大的差异，一般来说，整数倍处理器字长的数据，处理越快。而C的设计是为了解决汇编对人的负担带大的问题，但是又不可能忽略掉机器性能和内存存储的要求，至少在那个年代是这个样子。当然，现在这一点大多数时候已经不那么非常重要。以至于java的一个char都可以用2个字节，这个在当时肯定是大逆不道的，而且也不分有符号和无符号，这些统统被jvm屏蔽掉了。其实我觉得，asm/C/C++等是一代的，其后的Java/C#/...才是真正的高级语言。但是并不是说asm/C/C++不高级，只是用途不一致罢了：）

幻の上帝

回复 91# walleeee

>> C++正如其官方的说，提供了4中编程模式
官方？谁？
>>是对于绝大多数（99.999999...%）的人来说，多余的选择并非好事，也是负担，不知道你认同这一点不？
大道理说的是没错，不过这举的数字使你的话好像有一些Win用户数落*NIX的口气。
>>其次，语言过度设计和语言写的东西过度设计的本质来源在于语言自己提供了太多的选择，就像大杂烩，是一个组合级数的爆炸增长。
你是这样认为吗：比起不恰当的接口使人无所适从，提供正交的丰富的接口本身就是过度设计？
>>有很多的语言使用者有各种各样的恶习，把简单的事情复杂化，这一点我也不懂是为什么
这个我同意，同时我也很遗憾我搞不清也为什么会有这样的现象，也无法改变现状。
>>这一点看来你是支持C++了？
在这个特性上我中立。我自己是不会去用很花哨的东西，但是想到可能又会有一些低质量的代码因此增多，我不得不捏把汗。
>>我已经原理STL这种没什么大用，而又很复杂很低效的东西，因为他太不可控了，根本就无法根据需要进行调整。
就提供了能节约时间而言比C还是强一点。用的时候才发现不可控就太后知后觉了。至于复杂和低效，C也一样——你几乎无法用语言直接控制语言实现的状态来改变它行为，让它使代码看起来不复杂或高效。另外，有些东西是C学习了C++才不那么低效，像inline。“根本就无法根据需要进行调整”——是指调整什么？
>>至于你说的泛型，的确有用
是给C风格的静态类型系统擦屁股。因为弥补了一些核心语言特性的不灵活性，所以有用。
>>代码是在表达你的需要，同时也要让其便于让别人理解你想要什么。自己一时少些，偷懒，到头来害了别人，甚至有可能害了自己。
没错。但我举的例子用auto会影响可读性么？至于把语言特性用在不适用的地方乃至滥用，引用某人的话，“人的问题”。
>>这样一来，别人读你的代码就少了类型信息，如果很多变量都是这种缺乏类型信息的，那么读者会很头大
是么。至少在我举的例子上我不觉得。
>>另外这种方式实际可能会降低编译速度（当然你感觉不明显，但是如果是大工程你就知道了）。
请给出数据。理论上来说自动类型推导是会降低速度，但是照这么说复杂的嵌套类型的语法分析也会降低速度。哪个更多一些？
>>再次说明，以上是个人观点，可以讨论或者提点，但是请不要抨击，更别污蔑，说的有道理，本人会真诚感谢：）
赞同你讨论的态度。

幻の上帝

回复 92# walleeee

>> >>int x[], int[] x
>>这个只是个人喜好，我觉得并不是什么大问题，前面一种侧重说明x的元素都是int类型，而后面一种侧重说明x是一个int[]的类型。一个强调元素，一个强调变量本身。但是它们的功能在编译层面来说都是等价的，不知道你同意不？

表面上来看这样是没错。但是你归纳一下语法，再考虑一下当这种规则递归使用的复杂性的时候，可能就不会这么认为了。
举个例子：
http://bbs.chinaunix.net/thread-3619087-1-2.html
void (*tpsetunsol (void (_TMDLLENTRY *)(*disp) (char *data, long len, long flags))) (char *data, long len, long flags);
读起来爽么？写起来爽么？为什么这种东西能顺理成章地招摇过市？（编译器大概是没啥感觉……）
（严格来说还有那么点不公平：这里人一眼看过去很快搞清具体声明的是哪个标识符是不太靠谱的；机器可以和前面已经声明过的标识符比对，一有问题就罢【河蟹】工。）
再想想lisp之类如果改用中缀表达式那会如何？
编译层面是等价的，是的，对机器而言如此（标识符超长之类不考虑的话）；但是，别忘了，这些代码的一部分价值来源于可以给人类阅读。既然如此，容易高效读写的东西好呢，还是顺应历史，认为很容易导致低效的方法更好？

>>这个是没办法的，要看当时的机器工艺，cpu对处理这些数据使用了不同的指令支持，另外，这些数据类型不同，在cpu级别上的效率也有很大的差异，一般来说，整数倍处理器字长的数据，处理越快。而C的设计是为了解决汇编对人的负担带大的问题，但是又不可能忽略掉机器性能和内存存储的要求，至少在那个年代是这个样子。当然，现在这一点大多数时候已经不那么非常重要。

于是时代的眼泪要与C共生共死么。

>>其实我觉得，asm/C/C++等是一代的，其后的Java/C#/...才是真正的高级语言。但是并不是说asm/C/C++不高级，只是用途不一致罢了：）

倒是有那么点感觉。不过C++离asm/C渐行渐远了。

幻の上帝

LZ对不起我继续歪下楼。这回是彻底歪了。
我对于程序设计语言的喜好并不主要由我已经实际用它解决了多少问题决定，而是直觉意义上的简单性，这包括：
1.写一个这种语言写的一般意义程序是否足够简单；
2.读上面写的程序是否足够简单。
无论如何，这里耗费大脑CPU时间最大的部分是表达的意义的解读和重现（至于记忆关键字和语法之类的，人适应起来比计算机快得多，而且也是一次性投资，不用花精力重复学习，相比可以忽略）。
通常人不自觉地分析和实现语义会用到以下几类方法：操作语义、指称语义和公理语义。实际上这是有严格定义的方法，不过我这里泛化地指和这些方法接近的方法分类。
举个例子：认为学C需要先学汇编的，是在说操作语义王道；一般的C教材是以指称语义为主，操作语义为辅；C标准则混合三种方式解释语义，且公理语义>指称语义>操作语义。
这些方法都有合理的成分，但单独任何一种方法都有其局限性。例如操作语义抽象困难，指称语义容易过度抽象，公理语义在描述和解决问题上手续繁杂。我认为具体使用哪类方法，应该看需要而定。如果定义一种新语言，那么采用公理语义方法奠基会比较简单（像Lisp）。可惜C语言不是，它混合了前两者，最缺乏第三种方法，并间接导致各个实现之间的差异过于明显。后来标准化的时候不得不添加许多细节，我想这是主要原因。
我认为我的大脑最适应于指称语义方法，它对于解决来自于普遍的问题域的问题最具有操作性。引用喂鸡：
指称语义的一个重要原则是“语义应当是复合性的”: 程序段的指称应当建立自它的子段的指称。最简单的例子是: “3 + 4”的意义确定自“3”、“4”和“+”的意义。
于是学习和解决新的规则的复杂度是线性的。操作语义方法效率可能近似或略高，但它的前期准备需要占用远远超过线性的空间复杂度；而公理语义方法在解决问题时效率都远远劣于指称语义，尽管它的解的质量可能更高。
所以不得不死记各种语法细节的才能算会用，会用之后仍然得靠冗余关键字来“帮助”我写出正确代码的语言我并不认为对我有多少价值，即使这类语法本身只是很少的一部分。
C在这个方面上做的还好。没有BASIC的啰嗦也没有PASCAL的死板，却也不算很不严谨而无从归纳，对规则的指称进行抽象还是可行的。算是取得了一个平衡。
可惜由于时代的局限性，在静态类型系统上做过了头。被写死在语言规则的类型语义不可能无视，迫使我付出防止习惯于语言的规则影响思维的代价。在必要时突破这种障碍的唯一设施就是借助于类型转换的void*，如果不算宏的话。
而C++在这点更精确更容易。所以我认为C++至少更适合我。表面上的复杂已经被习惯地过滤掉了，C++对我而言并不比C难多少（标准文本倒是啰嗦了不少，但更清楚）。
我不认为C++在一般意义上更优秀。但它至少能让我的思维更简单轻松，如此而已。（对于学一门语言就要用这门语言思维的人来说就算了，鸡同鸭讲。）

zylthinking

你当楼主吧，我不管了。
因为这个帖子， 闹得几个人要跟我决战， 我要不要把楼产证给你？

幻の上帝

回复 96# zylthinking

歪楼能力自觉不够，还是免了。
到贴吧继续锻炼去了……

walleeee

回复 93# 幻の上帝


>>官方？谁？
呵呵，好几本都里面都有说这个，具体我也记不清那么多，不过我给你找了几篇wiki看看
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/C%2B%2B#cite_note-shildt-1
大略是面向过程，面向对象（尽管这个概念在技术领域名声不好...），函数式，泛型

>>大道理说的是没错，不过这举的数字使你的话好像有一些Win用户数落*NIX的口气。
...好吧，既然你这样认为，我认输，但是绝对不是你想的那样 ：）

>>你是这样认为吗：比起不恰当的接口使人无所适从，提供正交的丰富的接口本身就是过度设计？
这个我不太明白你的意思，你是想表达我认为“正交的丰富接口就是过度设计”这一观点么？我不是这个意思，正交而丰富的接口本来就是接口设计的原则之一，任何程序库的设计者都应该深刻理解正交和丰富的概念。

>>这个我同意，同时我也很遗憾我搞不清也为什么会有这样的现象，也无法改变现状。
看看各种设计模式，特别是java的一些设计书籍，就会看到各种各样的过度设计。即便我不说他们方法过度了，至少把那些个教学方法用在他们的例子上那就是过度设计。编程语言也好，设计模式也好，还是什么编程模型也好，不都是为了减轻程序员的负担，提高程序员的效率，从而真正提高软件质量和保证软件开发的可控性。而你看现在的一些软件工程方法，是否有一些本末倒置了...这些都是个人蚍蜉之见。

>>在这个特性上我中立。我自己是不会去用很花哨的东西，但是想到可能又会有一些低质量的代码因此增多，我不得不捏把汗。
中立是一个很好的选择：）
我也中立，尽管我用C++，但并不意味这用C的人比我更懂C，呵呵
总之，语言应该是用来表达你的思想，只要能明确而轻松的表达你的意图，你说英语和中文又有什么关系呢？这里有一个小故事：
我大一的时候问我老师，是不是除了学英语，还应该去学学日语，因为将来可能会去日企，这样可以增加就业机会。但是我老师跟我说，学好英语就可以了，数学家的交流不需要语言。
我不说这个说法有多正确，至少说一明一点，语言的本质应该是让你轻松而充分的表达你的思想，而非其他，尤其是带来争执。

>>就提供了能节约时间而言比C还是强一点。用的时候才发现不可控就太后知后觉了。至于复杂和低效，C也一样——你几乎无法用语言直接控制语言实现的状态来改变它行为，让它使代码看起来不复杂或高效。另外，有些东西是C学习了C++才不那么低效，像inline。“根本就无法根据需
要进行调整”——是指调整什么？
C其实宏也蛮好用的，只是我不知道为什么这么多人抨击，就像goto，我个人觉得都蛮好的，看场合了。调整是指STL内部的各种扩展算法，比如内存分配器等。C其实也有很方便的封装，比如glib/gtk+就很不错，我觉得学C的人都该去学学glib/gtk+等的数据抽象技巧，也很方便易用。

>>是给C风格的静态类型系统擦屁股。因为弥补了一些核心语言特性的不灵活性，所以有用。
你的说法有一定的道理，但是我并不太赞同，所以我保留我的观点。其实所有语言（所有的计算机编程语言）在计算能力上都是图铃等价的，没有谁比谁更强大，他们的区别只是谁比谁更方便。C++在做泛型和数据抽象的时候相较于C的确是高级语言。

>>没错。但我举的例子用auto会影响可读性么？至于把语言特性用在不适用的地方乃至滥用，引用某人的话，“人的问题”。
我都是说工业级别实际生产中用的代码，例子代码也应该按照这个要求要强制，不然又有很多同学会照着清华某“砖家”书里的“例子代码”来写而丢了工作：）

>>是么。至少在我举的例子上我不觉得。
参上

>>请给出数据。理论上来说自动类型推导是会降低速度，但是照这么说复杂的嵌套类型的语法分析也会降低速度。哪个更多一些？
这个我是说“可能”，只是直观的感觉，因为这一点我目前没有具体的数据，而且也没时间去研究G++。但是我说这个话是很有把握的，不信你也可以自己测测。（ps.找个大型的工程，比如qt，然后把里面所有函数内的变量都改成auto，这一点用sed比较好做到，然后再来编译一下）

>>赞同你讨论的态度。
tks

walleeee

回复 94# 幻の上帝

>>不好意思，我不太明白你的意思。你觉得这个函数声明改用你那种形式会很好？很清晰？我觉得更多的是这个函数自己的风格就有些过了。
当然，这是个人品味问题，不多深究。

>>于是时代的眼泪要与C共生共死么。
计算机工业的发展，兼容是非常重要的一个原则，如果不是迫不得已，没办法兼容了，后续产品都是必须兼容前代的。所以，必须共生共死。
而且，C语言不见得只是给传统的体系结构编写程序，还用在各种各样的体系结构上，你可以让C把所有的整数都当成一个类型来处理，但是其他人呢？做密码的可能需要能处理字节，做普通软件的可能希望能处理字符。C是为了适应各种需求而精心设计的类型系统，当然也可能会给一部分人带来很小的不便，这个是没办法。另外，要明白，现在跑在各种机器上的总代妈量中有70%都是很老的代码，甚至几十年前的代码，他们不活了？

>>倒是有那么点感觉。不过C++离asm/C渐行渐远了。
不，asm/C/C++还是一条船上的，看你选择了。

walleeee

回复 95# 幻の上帝


    C++那个iostream系列，就是反人类，比scanf/printf系列不知道好在哪里，格式化一个字符串还要一个stringstream，而且还乱七八糟的各种控制。而scanf/printf系清晰明了，简单整洁。包括新出的boost的字串处理都是一塌糊涂。

zhzh8015

迷失在Linux的海洋里