确认一下c++中不能使用interface（如java）那样的功能把

OwnWaterloo

向你请教几个函数式编程的术语，望赐教， 谢谢～～
关于，currying 和 partial application。

对一个函数r f(p1,p2,p3, ... );

将其柯里化 curry(f)

得到的是一个函数g， 该函数接受单个参数p1， 返回另一个函数g2。
而g2是一个接受f余下参数， 返回和f相同的函数？

g = curry(f);

将某个参数带入，
curry(f)(a1) == g(a1);
g2 = g(a1);

得到的g2， 是 f 的partial application。 同时
g2(a2, a3, ... ,an) == f(a1,a2, ... an);

或者， 不使用中间环节， 直接：
curry(f)(a1)( a2, a3, ... , an) == f(a1, a2, ... ,an);

也就是说， C++中， bind机制的产物， 对应的概念是g2, partial application 而不是currying？
我的理解对吗？

OwnWaterloo

原帖由 OwnWaterloo 于 2009-4-9 14:19 发表
因为C++没有二进制标准。  其实这是我对C++最不满的地方 ……  许多时候都麻烦死 ……

多说两句， C++的实现比标准出现得早得多。
在标准出现之前， 已经有许多C++实现以不同的方式去实现C++的特性。

标准如果强制它们遵循同一方式去实现这些特性， 必然是得不到响应的。 应为C++是独立于商家的语言。
而不像java（一开始）、C#， 它们自己就是标准，又有公司撑腰。 二进制标准当然想怎么定就怎么定。

reiase

原帖由 OwnWaterloo 于 2009-4-9 14:40 发表


哪些提议？？？


你指的机会成本， 就是C++的动态优化几乎被禁绝了， 是吧？

错！我再给你举很多例子
1. C++为了实现编译时重载，引入了name mangling技术。这直接带来了两个问题:连接器不友好和连接器不友好（也是我不喜欢C++的直接原因）。不同的编译器使用不同的mangling规则,使得跨编译器连接变得极为困难.name mangling也使得非C家族的语言,调用C++代码困难,因为你不能再ELF上定位函数入口地址,符号表里的符号是编码过的.其实C++的编译器不友好另一部分原因是操作系统设计的时候,全面面向C API的历史原因造成的.不过主要原因还是在C++选择的name mangling技术
2. C++使用了C风格的头文件.这直接导致了臭名昭著的Header宏的出现,而不能像jave以及C#等语言那样，使用import或者using。这个问题俺讲不来，没那水平讲清楚。关键点：为什么C++中类声明为什么不能重复出现
3. 还是前边提到的那个疑问，你没回答我。模板实例化出来的函数是不是具有内部连接属性，也就是static连接属性的。如果是，那么模板是否会造成编译后二进制文件的体积变大，如果不是，那么一个模板在两个库中用相同的参数实例化怎么办，会不会造成连接时符号冲突。如果模板实例化的函数具有内部连接属性的，那么就不能够使用模板批量实例化GUI里边的回调函数，或者这类应用。难道模板仅局限于容器嘛？
...就这些吧，还有很多C++机会成本的例子，可惜俺水平不够，写不出来
俺C++不行，仅仅是从C程序员的角度表示对C++提供的一些特性不是很信任。其实为了工作，C++是一定要学的。只是在学语言的过程中，俺严重的感觉到，不同语言的社区，里边的人是绝对不一样的。比如python社区坦然面对python性能与GIL的问题，perl社区也能够坦然面对perl程序难懂的批评。起码我看这两本书的教程时，作者是提到过的。而C++教程则一般是“进入面向对象程序语言的精彩世界...”云云，很少看到对自身问题的反思。

reiase

原帖由 OwnWaterloo 于 2009-4-9 14:40 发表


哪些提议？？？

先说说那个函数式编程的脚本语言， 效率超过C++的问题。  我又仔细想了想， 觉得是彻底的被你给忽悠了。

几个问题，
1. 这是编译型语言， 还是解释型语言？
2. 如果是编译型， 这个优化是运行时， 还是编译时？
3. 如果是编译时， 对优化就只能是常数？？

俺没说是什么语言，这个虚构例子是俺在erlang/haskell教程上看到的，目前对此感兴趣中。如果尾递归消除用在图像领域，应该能够减少不少计算量

真实的例子也有，是一种脚本还是什么语言的，在一个专业领域的应用中速度大幅领先，因为和自己心目中的结果相符，所以我没怎么分析过。兴许你能找出点什么可疑点，分析一下。下边是连接
http://bbs.chinaunix.net/viewthread.php?tid=1291900

reiase

网络卡，重复回帖，编辑掉。望版主帮忙删除

[ 本帖最后由 reiase 于 2009-4-9 19:26 编辑 ]

OwnWaterloo

原帖由 reiase 于 2009-4-9 16:55 发表

1. C++为了实现编译时重载，引入了name mangling技术。这直接带来了两个问题:连接器不友好和连接器不友好（也是我不喜欢C++的直接原因）。不同的编译器使用不同的mangling规则,使得跨编译器连接变得极为困难.name mangling也使得非C家族的语言,调用C++代码困难,因为你不能再ELF上定位函数入口地址,符号表里的符号是编码过的.其实C++的编译器不友好另一部分原因是操作系统设计的时候,全面面向C API的历史原因造成的.不过主要原因还是在C++选择的name mangling技术

不name mangling， 怎么高效实现重载？？   我真不知道其他语言重载是如何实现的。。。

而且， 你真正讨厌的不是mangling， 而是标准没有规定mangling的方式， 不同编译器对其有不同的mangling方式， 没错吧？
在上面我也说了， 我也非常讨厌C++没有二进制标准。
对mangling， 更加讨厌， 因为相对于对象模型， 统一mangling其实并不困难。
可是， 谁能让目前的编译器厂商乖乖听话， 统一起来呢？
比如有个公司喜欢非常私立标准， 对C++标准能支持到目前的程度我都觉得很惊讶了。 当然， 它的作法是遵守标准， 同时提供大量扩展 ……

标准委员会， 一个没钱没势的组织， 能强迫它么？？？

原帖由 reiase 于 2009-4-9 16:55 发表
2. C++使用了C风格的头文件.这直接导致了臭名昭著的Header宏的出现,而不能像jave以及C#等语言那样，使用import或者using。这个问题俺讲不来，没那水平讲清楚。关键点：为什么C++中类声明为什么不能重复出现
 

关键点：  C++把“尽可能与C兼容”， 放在很重要的位置。
如果C++不这样做， 可能根本就不会流行起来。


你说的Header宏， 是指 header guard 吗？
这个：
#ifndef SOME_FILE
#define SOME_FILE
// ...
#endif
？

为什么类声明不能重复出现我不清楚， 但是， header guard从来不是开发中的障碍 —— 又一个关键点。
如果觉得写着麻烦， #pragma once 也是很多编译器都支持的扩展。
没有import 或者 using ， 确实要麻烦一点，  但是， 这是障碍吗？  值得称之为“臭名昭著”吗？

相反， C++还引入了许多方式， 减少对宏的使用。

原帖由 reiase 于 2009-4-9 16:55 发表
3. 还是前边提到的那个疑问，你没回答我。模板实例化出来的函数是不是具有内部连接属性，也就是static连接属性的。如果是，那么模板是否会造成编译后二进制文件的体积变大，如果不是，那么一个模板在两个库中用相同的参数实例化怎么办，会不会造成连接时符号冲突。如果模板实例化的函数具有内部连接属性的，那么就不能够使用模板批量实例化GUI里边的回调函数，或者这类应用。难道模板仅局限于容器嘛？

我显然在440楼回答过这个问题 ……

原帖由 reiase 于 2009-4-9 16:55 发表
仅仅是从C程序员的角度表示对C++提供的一些特性不是很信任。

很简单， 用你信任的特性就可以了。 如果你对其他特性感兴趣， 去研究， 信任， 用之， 或者鄙视之， 弃之。
C++提供这么多的特性， 是给需要的人用的， 并不要求使用其全部特性， 也不要求必须学习全部特性才能使用该语言。

原帖由 reiase 于 2009-4-9 16:55 发表
不同语言的社区，里边的人是绝对不一样的。比如python社区坦然面对python性能与GIL的问题，perl社区也能够坦然面对perl程序难懂的批评。起码我看这两本书的教程时，作者是提到过的。而C++教程则一般是“进入面向对象程序语言的精彩世界...”云云，很少看到对自身问题的反思

C++教程， 我也反复在说， 确实很多都不怎么样。
“进入面向对象程序语言的精彩世界...”， 说这种话的人， 只了解C++的一个子集。

肯写 python、perl语言教程的， 一般都是大牛。
写C++教程的， 就难说了。   因为后者的书更卖钱， 不管自己有没有货都想来捞一把。
而且不少都是借C++炒作某些公司的产品，比如一些Visual C++、MFC啥啥的。
你见过小软和太阳的书， 批评过自己什么吗？ 它们连windows 窗口都可以说成是OO的。



你说的什么社区，  我平时都没怎么注意， 我很佩服perl社区能坦然面对perl这个问题。
那么， C++社区呢？  UC算么？ C++的人吹嘘什么了？  或者说， 我吹嘘什么了？
相反， 倒是在一些公司专属的语言社区中 ……   那吹得才叫恶心 ……

[ 本帖最后由 OwnWaterloo 于 2009-4-9 18:01 编辑 ]

OwnWaterloo

原帖由 reiase 于 2009-4-9 17:09 发表
如果尾递归消除用在图像领域，应该能够减少不少计算量

尾递归是有适用范围的。 有多少递归能化成尾递归？？？
尾递归也不能消除计算量， 只是不存在栈溢出罢了。

或者是我对尾递归的理解有误？？？

原帖由 reiase 于 2009-4-9 17:09 发表
真实的例子也有，是一种脚本还是什么语言的，在一个专业领域的应用中速度大幅领先，因为和自己心目中的结果相符，所以我没怎么分析过。兴许你能找出点什么可疑点，分析一下。下边是连接
http://bbs.chinaunix.net/viewthread.php?tid=1291900

这个链接在上面很多很多楼你就贴出来过了。
也有人说过了， 是否是商业吹嘘？  还是仅适用于特定领域？


前几天还在top language上看到一个 python和C++比排序的帖子 ……  忍住没和他争论 ……
还是那句话， 比较两门语言， 请首先熟悉两门语言。
不要拿着cygwin编译出的exe和XX语言比效率（忘记是啥语言了——以前一个很火的贴……  堆了很高的楼， 最后楼主说他用的cygwin……）。
或者拿list来排序 —— top language上的例子 ……  在这里发泄一下。。。  免得又上那去吵。。。

[ 本帖最后由 OwnWaterloo 于 2009-4-9 18:33 编辑 ]

beepbug

原帖由 OwnWaterloo 于 2009-4-9 18:12 发表


尾递归是有适用范围的。 有多少递归能化成尾递归？？？
尾递归也不能消除计算量， 只是不存在栈溢出罢了。

或者是我对尾递归的理解有误？？？

尾递归同样存在栈溢出。

reiase

咱们两个讨论的关键点在于：我认为C++的机会成本如何如何，而你不认为C++存在什么机会成本

好，按照所谓的微观经济学的说法，选择都是伴随机会成本的，如果你觉得我说得不对的话，那么你C++这么牛X，你自己讲下C++选择造成的机会成本有哪些好不好？

1. 那个连接器不友好问题。如何实现一般标准不能做硬性要求，比如，某些国内厂商可能像在中文化的C++中引入中文的name mangling

2. 模板那个问题。不知道你测试的时候使用的是什么连接器。据以前CU某大牛测试，gcc a.cpp与g++ a.cpp在连接阶段的行为是不一样的，这一点仅供你参考，你在测试的时候可能要注意下。而且，即便连接器在连接时删除了重复的那些个实例化的模板函数——你不觉的这个方案彻头彻尾的难看吗？

3. 头文件问题，俺说了为什么不能多次重复声明一个类？俺声明，俺没研究过这个问题（因为俺现在没有C++的需求 ）但是猜测如下：
a 结构体在C里边也不能重复声明，（或者说结构体根本就不存在声明，只有定义），类本质上是C的结构体，所以继承了这一缺点，但是C程序如果设计好的话，可以让头文件里不包含结构体声明，只包含结构体指针的声明。而函数是可以重复声明的。
b 编译器在读取一个类的声明时，就为该类生成了很多很多代码。重复声明类，会造成这些代码被重复生成
c 在编译之后，类的信息就全没了，所以编译器无法判定哪两个类声明指向同一个类
所以，俺说了，这个头文件的问题一直困扰我。俺从这一点觉得，这是C++在OO方面一个深层次问题的表现，但是俺不知道是什么问题。这个还请指教

4 小软和sun

你见过小软和太阳的书， 批评过自己什么吗？ 它们连windows 窗口都可以说成是OO的。

Sun在自己的书中承认，CPU没Intel快...那个小软，俺不清楚(你看，俺记性很好的。如果C++社区某牛人承认C++的哪个不足，相信俺一定也会记住的)

5 那个函数式编程的问题，俺回答不了，没那水平。俺函数式编程是在python下进行的...但是现在处于放弃的边缘，主要是Cython之类的工具目前不支持闭包，俺写的N多代码为了用Cython提速不得重写成过程化的代码。俺不是计算机专业的，不要跟俺玩术语，currying 和 partial application是啥

[ 本帖最后由 reiase 于 2009-4-9 19:24 编辑 ]

reiase

还有，即便是忽悠你，俺讲的那个”超线性收益“和”脚本速度超越C++“，都是有出处的。
前者是论文，后者的网址也给你了