强烈建议CU分出C++版

fallening

回复  fallening

看起来是不错，不过不发明轮子却总是造轮子也不行啊。
boost.signal是抽象层次太多裁 ...
幻の上帝 发表于 2011-11-12 13:21

确实是这个问题，如果不要 priority 的话，带缺省 priority 实现的 signal 效率不够;
好吧，注意到这个问题之后，如果让我再造一次这个轮子，我可能把它抽象出来做一个 policy。但是这样一来，又向 boost 的层层抽象的实现靠近了一步

songvar

C++用惯了，倒是觉得C的面向对象很简陋，很搓澡，很难看

James_think

btdm123

分出去好，实际上是两种语言了

sonicling

C++的传统是吹个NB，把你套进去然后宣布：那个NB太搓了，俺们已经不屑于那个NB了

比如面向对象，各种使用 ...
reiase 发表于 2011-11-12 13:55

    内存布局又不是C++规定死的，各个编译器可以有自己的方案，只要达到标准要求的效果就可以。你觉得那个内存布局不好，你可以提出一个更好的啊。标准并没有所谓的“硬规则”，标准描述的只是面向对象所应该具有的语义。至于编译器实现成这个样子，即便是有遗憾，那也是迫不得已，否则也轮不到你现在来抱怨，早有人会去改进。

我对异常也比较抵制，但是我并不认为就应该把它踢出去，毕竟异常设计本身已经很不错了，它的适用范围和能力比C语言的setjmp/longjmp要强不知多少倍，而后者才是把地地道道的双刃剑，就算你深刻理解它，你都未必敢用。而异常有完整的语义模型，有编译器帮你兜底，不会有那么多顾虑，理解它的人很少用错。

lambda表达式的类型定为function object的确比函数指针更好，理由bs早就说过了，function object可以内联优化，而函数指针不行。另外如果如你所愿，把lambda定为函数指针，看似简单，一旦涉及到函数原型、类型转换、变量存储之类的问题，一定会出现一大堆粗劣而不可靠的设计，而这些连带责任最后都会算在C++头上，于是又会被群起而攻之。不要拿python等辈来说事，他们有解释器兜着呢，而C++是裸奔在真实的CPU上的。

面向对象的目的是为了降低对象间的耦合度，从而最大限度的提高软件的可扩展性和可维护性，是软件工程里最重要的软件开发方法之一。单纯的为了对象而对象，那是bruceteen在12楼所说的基于对象，这是所有面向对象语言的都存在的问题，而且根源在于人而不是语言本身。（面向对象是方法，并不一定需要语言特性的支持，所以C语言很爽，很少有人在这方面指责它。倒是不少人总是抱着双重标准，在C语言那儿说面向对象是思维方法，到C++这儿却当它是语言特性，这对C++很不公平。最近还发现有些人想尽方法用宏来让C语言支持所谓的“面向对象”，的确很蛋疼。）面向对象之所以能流行，是因为它的确可以提高软件的可扩展性和可维护性。如果这两个特性并不是你的软件的主要考量，那么就不要在喝汤的时候说叉子不好用，兜汤请用瓢。

幻の上帝

回复 61# fallening

主要问题是，造轮子受到需求变化的影响，对于通用的东西来说实在很难一次就保证造到位。boost这种造足够“大”轮子的策略可能是不得已而为之的一般意义上正确的解决方案。
C++和C一样，声明一个东西，“是什么”在编译期一次性完全确定。你没办法声明出一个既可能是函数又可能是类型又可能是变量之类的东西，就算你知道这个东西之后肯定会在编译期确定也不行。模版基于部分structural typing在这个方面上能克服一些困难，但是终究无法解决问题。这个在抽象的灵活性上不够的问题，导致减少重复制造轮子的一些实际障碍：你不得不给你制造的轮子限制相当明确的使用范围，这无法使它在需要时很方便由用户补充代码来指定屏蔽掉一些东西而不损害其它部分的可用性。
说到底还是语言的限制，哎，适用就好。

幻の上帝

回复 65# sonicling

面向对象作为方法论是指“可以这么理解”，最大的意义就是在于建模的过程中提供一套可能使人容易理解抽象的手段。降低对象间的耦合度是之后更细化的手段的任务了。
如果光面向对象就能解决这个问题，面向接口又算什么？
我认为面向对象的流行主要原因是给用户降低抽象问题域的难度的某种自由（或者说，对全面理解问题这方面的智商的要求比较低 ）。一个设计者可以不必了解整个任务而设计其中的一部分，用面向对象的协议来和其它设计者协调以便实现他的设计。这对软件工业来说有益于节约成本，但设计的总体质量未必能更好。话说要是都只知道鼓吹纯面向对象，那么这个领域的平均智商会到什么层次呢……

sonicling

回复 67# 幻の上帝


    是的，我没有说全。面向对象的目的除了包括可维护性、可扩展性之外，还有诸如复用等，而抽象是它的重要手段。有了抽象，于是降低了耦合，于是可以复用、可维护、可扩展。

至于面向接口，我觉得他和面向对象的关系不是在同一个层面上的。我认为面向对象是程序设计的基础方法，它衍生自结构化程序设计方法，而从它又可以衍生出其他的设计方法，如面向组件、面向方面、面向角色等等。从面向对象衍生出来的其他方法都解决了面向对象的一些没有关注到的地方，例如面向组件的提出是因为对象的粒度太小，当一个系统有成千上万种对象，或类时，这些类的管理就是一个大问题，而组件就是在大粒度层面上对对象再次划分、封装、抽象，并借助接口来连接组件。而面向方面的提出是因为有很多时候，对一些具有多个平行特性的对象进行抽象和划分有些复杂，只能分方面来解决进行划分和抽象。

而面向接口方法，如果真的把他当作一种方法的话，我认为也只能算是面向对象的一个子集，因为接口本来是面向对象的重要概念。

shang2010

{:2_169:}

reiase

回复 65# sonicling


我觉得内存布局无关的OO才是好OO，才可能简洁优雅地实现OO。你也承认C++的OO实现地有点迫不得已吧。其实这完全是看事情的角度问题，你如果多玩玩几种OO语言，你也会觉得对某个语言不满很正常。

异常的语义我并不关心，语义是一回事，实现是另一回事。没垃圾回收，异常很容易造成的资源泄漏。理解那个异常的语义我一点都不关心，理解了语义，写代码时该纠结还是纠结。我懂了异常的语义，异常就能更好的作资源回收吗。编译器兜底管毛用。

说白了，用C++就是这样的场景：
C++：C++很NB，支持异常处理呢。
Java程序员：是吗，性能又好，又支持异常处理。好，我也去用C++

Java程序员：为啥内存泄漏了阿
C++：你娃太SB了，异常处理里边没有正确释放资源阿
Java程序员：异常处理还要释放资源阿...我只想要用异常阿，不能自动回收，我还是不用了吧

语法上支持只是第一步，你要有配套的，完善的一套机制。说白了，大家都有自己的领域，自己领域的问题还解决不过来，谁有经理扣你语法，扣你语义。说白了，就跟很多语言里，自娱自乐的搞一些库没啥区别，比如tcl这种语言也能写一个Web框架，但你说tcl对Web支持好就自欺欺人了，tcl的Web框架也就一帮专业tcl程序员自娱自乐，给自己的tcl程序添加一些蹩脚的Web特性而已，没有NB的正则库和模板库，Web也不好做。C++和C++库里边特性很多，其实很多特性也就是一些资深程序员自娱自乐用。

另外，OO已经不是C++的语言特性了吗？