西西河

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

共:💬100 🌺284
全看分页树展 · 主题 跟帖
家园 讨论一个特性的得失应当看它的机会收益

首先这里有一个各个编译器的name mangling方式的表格:http://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions

这充分显示,重载的引入不是危害到单个的程序员,而是危害到整个C++社区。它导致:C++的函数库,如果不经特别处理,只能在C++里面。未处理的动态库里面的函数,C不能使用,Python不能使用,甚至连C++自己也只能由使用同一编译器的同一版本编译的代码来使用。微软当年搞COM的一个直接的原因就是C++ ABI层次上的不兼容,否则RPC的方案就足够了。这使得整个C++社区和Java社区那样,他们的成果很难在其他社区推广,而其他社区为了实现同样的功能,只能再去开发一套C的版本。

如你所说,重载的实际使用是很少的。所以让任一函数皆可重载这一设计的代价已经远远超过了它的收益。这一设计只不过是满足学院派对于语言内部自洽性的个人偏好。允许大部分的函数不重载直接出现在名字表中以向下兼容,同时提供特殊的语法来显示地解决重载问题,现在看起来才是最合适的。

同时我并不反对引入泛型。我只是不清楚Lisp里面两三页纸能讲清楚的问题,C++为什么要用好几本书。本来是很简单的一件事,可是有人却试图让所有的地方都适应它,同时为了简洁又不愿意多引入一些可以让它方便化的工具,最后就成了一个备受诟病的极其复杂的设计。

其实泛型完全可以变得更为简单。举个例子吧,我们经常看到极长的尖括号用法。为什么不能缩写一点呢。原因是,最简单的缩写方法是宏,而有些人已经意识形态化地把这个东西批判到死了,重新谈宏方法的简洁有效性,不是扇自己巴掌么。剩下的方法是typedef,可是他们又不允许去typedef一种模板。现在怎么办,他们只能用极其繁复的方法去搞什么"泛型编程",用一种初学者看起来高高在上云里雾里的方法去实现本来很简洁的功能。每次看到这些模板库实现,我都想狠狠地抽一下这些人,他们让很多人为他们的无知和偏执付出代价。

全看分页树展 · 主题 跟帖


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

Copyright © cchere 西西河