五千年(敝帚自珍)

主题:庆祝Python跃居世界第四程序语言 -- 空格

共:💬100 🌺284
全看树展主题 · 分页首页 上页
/ 7
下页 末页
家园 话说音译应该是“拍桑”吧
家园 我倒觉得Java和C#出来的没一个不是垃圾

这些语言本身其实还好,但一开始的风格彻底搞坏了,导致后面出来的东西无法不成为垃圾......

家园 明显假的

“任何人只要长了半个大脑也应该明白面对对象编程是荒谬而不合逻辑的,而且效率低下。”看到这里我就知道整篇文章就是在扯淡了。

家园 C++ ABI不兼容确实是个大问题,但是不光是重载引起的

C++ 每引入一个新概念,ABI就要改一次。不光是重载,还有exception, RTTI等等,都需要修改ABI才能支持。所以用c++最好不要编译成动态链接库的形式,要么用静态链接,要么用extern "C", 只提供C语言风格的入口。

C语言相对简单,其ABI的升级已经基本完成,除非重大升级比如libc.so.5到libc.so.6; 不像c++, g++4.1和g++4.2编译出来的.so都不能混用。

C++混到现在这个尴尬的地位,和高高在上的C++标准委员会有极大的关系。这帮人一是行动缓慢,二是沉迷于语法细节,以繁琐为乐。我怀疑这个委员会是不是欧洲人占主体所以才这样。美国人采用的是实用主义哲学,以简单好用为追求,比如C, 比如TCP/IP; 欧洲人以精确严谨为追求,不在乎用户接不接受,比如C++,比如ISO-OSI七层协议。

家园 c++真是个大酱缸,引入太多特性,太臃肿了
家园 同意,c++标准委员会运作模式与社区模式区别太大
家园 关于C++和脚本语言其实没什么好讨论的

两者根本就不是一个层面上的东西,一个是做应用的工具,一个是做工具的工具。数控机床好,削个苹果能有小刀顺手么?小刀削苹果快,给个铁块能削出个小刀来么?

程序员应该跳出语言的局限,适当的时候采取适当的工具完成任务。

家园 说点不同意见

重载,尤其是运算符重载,更尤其是圆括号()的重载是C++的一大优势。Functor的运用1)使得callback非常容易实现,和扩展。与C语言的函数指针相似,对被调用函数名称无限制,而更进一步增加了类型安全。2)与模板相结合,使得C++有能力与时俱进,在Function Programming流行的今天继续占有一席之地,比如boost.phoenix。boost.spirit更是运算符重载的杀手级运用,到目前为止我还不知道有哪种语言可以这样高效,无缝的内嵌表达式解析器,而且接口如此简单parse(target range,grammar,output).

家园 内存布局不规定现在看来

内存布局不规定现在看来,也许会是好事,使得在C++适应并行时代少了一些羁绊。

家园 我也并非完全反对重载

首先,我反对的是在所有域中不受限制的隐式重载。从实用主义的角度出发,类成员函数的重载是可以接受的,因为类成员函数相对于C来说是新的,可以在上面附加其他的功能,而且,类成员函数明确定义在一个域中,无论是功能上还是在代码上它们都是聚集的,并且限制在某个范围内,所以重名也不会引发理解上的问题。但是,对一个global scope里面的函数,隐式的重载使得其编译出来的代码和传统的C不兼容,而且会引发理解上的困难。例如:

#include <foo2.h>

void foo(float bar) {}

foo(1);

请问这个foo调用的是哪一个函数? 看起来它应当就是离它最近的那个函数,这理应是最简单的行为,但是C++中,如果foo2.h中有另一个void foo(int),那么它会调用另一个函数。这要求程序员和IDE都要做全局的分析以后才能知晓。如果我们禁止隐式重载,让重命名foo函数变为错误,而引入一个关键字overload做显式重载,那么会怎么样呢:

#include <foo2.h>

void foo_f(float bar) {}

overload foo foo_i;

foo(1);

不动的部分保持了和C的兼容性,foo_f, foo_i都被直接地暴露到名字表中,使得我们可以去掉export关键字,而且增加的overload关键字在程序中显式地标识出重载表,考虑到它可以重复声明,因此可以在离调用最近的地方重声明来方便程序的理解。同理C++中的exception等都可以用类似的方法加入,而不需要修改整个语言。这样做的一个额外的好处就是如果程序员坚持老的方式,他不需要重新学习什么东西,不需要改变自己来适应语言的变化。

其次,我反对C++现在这样的运算符重载。我认为Python的运算符重载方式更为优越。对于一个类,除非用operator关键字声明,除非在C++中使用运算符,否则一个程序员无法用别的方式重新定义和使用这一功能。所以C++的书里面必须单独辟出一章来讲运算符重载。其实运算符重载只不过是成员函数重载的一种特殊形式。如果我们强制规定类的__exec__方法对应operator (),那么,程序员就不需要额外学习运算符重载,他可以持续地按普通成员函数的方式定义和使用__exec__。而且,对于非C++的语言,也可以通过调用__exec__方法来复用C++程序员的成果。

Boost.spirit这样的模板库,我还是那个看法,看起来很精致,很美,但是不实用。在缺乏编译过程的调试工具的现状下,使用复杂的模板库,其开发时间会远远超过使用非模板库。而且就算神的代码一次性正确又如何,编译时间都会使得基于它的代码缺乏竞争力。很多东西都不需要我们来批判它,它会自然地被时间淘汰的。

通宝推:铁手,

本帖一共被 1 帖 引用 (帖内工具实现)
家园 我非常赞同你对C++标准委员会的看法

我认为overload和exception都有可以向下兼容C的实现方式,那就是,新特性新办法,老特性老办法,对C里面已有的东西要求引入额外的声明来显式地扩展:

http://www.ccthere.com/article/3313675

那堆人过于追求语言层面的精致,而不考虑他们的客户,也就是程序员,怎么在实际工作中去使用他们的产品

家园 爱词霸了一下,是“拍散恩”,多谢提醒。

汗,以前一直念错。。。

家园 应用层面,那就是C#了

有没有留意到,#就是两个加号叠加起来的?

家园 wxpython似乎还不支持python3.2

刚买了programming python

打算再找本wxpython的书来看

发现wxpython自己的主页上都是对python2.6, 2.7的支持

3.x以后的python还没有

家园 P+C/C++最好了

要运行速度有运行速度,要开发速度有开发速度。

全看树展主题 · 分页首页 上页
/ 7
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河