强烈建议CU分出C++版

三月廿七

自从我上次看到 部分Linux的代码
现在也放心大胆的用 goto 了，
来回 goto, 也装一回牛人

goto 可以将错误处理集中起来，
goto 可以避免定义额外的函数，
goto 可以代替递归

幻の上帝

回复 39# egametang


不好的地方是有的。
1、字写的多了，编译时间应该也要多；
2、==方便吗？
要说完全替代，还是别指望了。

linccn

回复 15# bruceteen

"面向对象属于鸡肋，它其实已经被C++放弃了，虽然没有赶出家门，但已经任其自生自灭"

给个出处吧

wait_rabbit

自从我上次看到 部分Linux的代码
现在也放心大胆的用 goto 了，
来回 goto, 也装一回牛人

go ...
三月廿七 发表于 2011-11-11 18:27

咱俩还挺像。我最近也开始不惧goto了，也是从内核里学来的。{:3_187:}

egametang

回复  egametang


不好的地方是有的。
1、字写的多了，编译时间应该也要多；
2、==方便吗？
要说完 ...
幻の上帝 发表于 2011-11-11 18:29

这是完全可以替代的，
编译时间不是问题，单核不行用多核编译，多核不行用分布式多机器编译

function带来的好处远远不止类型安全这么简单，配合bind可以把任何函数适配到function<void(void)>里面
上面多线程例子是调用了void Max(int a, int b, int*c),其实
void MaxN(int a, int b, int c, int d, int *e)也同样可以适配进去

w_anthony

class ThreadPool: private boost::noncopyable
{
private:
        int threadNum;
        boost::detail::a ...
egametang 发表于 2011-11-11 18:02

我让你举的是API的例子，你举的这个是吗？
API用指针做参数，即使是其他语言也可以调用，你的这个线程池模型可以吗？
另外如果真需要线程池的话，一般是比较大的应用，而且同时跑的线程相互之间可能还是有一些关系，而且因为这些关系，还是需要考虑锁之类的东西，还是需要一些定制，并不是这么简单的一句“线程安全哦”就可以解决的。如果是小应用，执行时间短，根本不需要开线程，执行时间长，你又不知道什么时候才能轮到你执行。线程池直接套用的机会，我个人感觉还真不多，我自己用的时候大都是特别定制过的，小应用真需要开线程就直接用API了，而且小应用一般也不希望引入这么庞大的东西。
另外，别人的API参数已经是函数指针了，你又如何回避？你不会指望boost把所有的API都像pthread_create和这个线程池这样封装起来吧？难道你要自己对所有有函数指针的API都做一遍如同boost一样的大封装？这可是一件大体力活。而且像信号中断回调函数那种，你要如何封装？

fallening

回复  bruceteen

"面向对象属于鸡肋，它其实已经被C++放弃了，虽然没有赶出家门，但已经任其自生自灭"
...
linccn 发表于 2011-11-11 20:06

我觉得 C++ 还有一个出处是 GP 和 FP，尤其是 c++11 引入之后

ah13k

C++ 11 除了那个转移语义还行（其实只是为了修复语言bug）之外，其他的对我而言意义不大，加重编译器负担，加重程序员负担。

神马lambda函数，浮云，语法糖

个人愚见，别轰我

egametang

我让你举的是API的例子，你举的这个是吗？
API用指针做参数，即使是其他语言也可以调用，你的这个线 ...
w_anthony 发表于 2011-11-11 21:22

1.你说哪个c库有指针我非得用它而没有C++版的？
2.退而求其次，有函数指针的库难道不能封装成fuction调用吗？epoll不是被boost asio封装了吗？
我用asio能10分钟写个简易server出来，epoll你要写多久才能达到asio的性能和稳定性？

w_anthony

1.你说哪个c库有指针我非得用它而没有C++版的？
2.退而求其次，有函数指针的库难道不能封装成fuction调 ...
egametang 发表于 2011-11-12 00:06

我对boost研究确实不深，所以我不知道它是不是对信号回调也有封装。另外确实所有的东西都可以封装，但是这种封装，一需要封装者体力消耗，二需要使用者学习成本。而且这种封装之后往往面目全非，就算你原本了解纯API怎么用，但是封装后怎么用，在没有学过的情况下可能完全不知道。还有一点这种封装都很重量级，是大体积封装，而不是“非封装”+“函数bind”就可以替代的。
更重要的一点，往往这些难用的纯API，Cer或者不用boost的C++er可能自己也封装过，而且不是用难以理解的复杂模版实现的，走惯了老路的人们有时候自然不想走新路。
另外很多C/C++使用者更愿意了解其实现本质，而boost的这种重量级封装完全无法起到帮助作用。最后还有少数boost使用者仅仅是会用，而不是考虑为什么可以这样，一旦有了这种的惰性，如果库没有提供功能的话，或许他什么也做不了，甚至有时候用错了方法都不知道怎么调试解决。
boost这个大东西，虽然有时候很管用，不过可以不用的时候，我觉得还是别引入的好，因为往往都是有很多替代的方法。
以前没有boost的时候，学会C++可能只需要X的时间，但是以后boost成为标准后，如果说学会了boost才算学会C++，那么培养一个C++er需要3X的时间（否则可能看不懂别人的代码），那么boost也确实加重了学习负担。boost有些封装确实比较蛋疼，多如繁星……
我承认这种抵制也并非是理性的抵制，或许与Cer排斥C++有那么点相似性。或许C1X真正出来的时候，你自己都不可避免的排斥它（比如这里一个malloc或者vector就可以解决的，为什么用垃圾回收的东西啊之类的）。所以应该要体谅Cer……