Chinaunix

标题: 强烈建议CU分出C++版 [打印本页]

作者: egametang 时间: 2011-11-11 13:47
标题: 强烈建议CU分出C++版
1.讨论异常时，一帮人说，我只用C……(你用C跑来讨论干嘛？)
2.c++没开发出大型软件……(眼睛长在屁股上吗？)
3.面向对象无用论(把c++ c# java等全给否定了，就你行，行了吧！)

强烈建议分家，井水不犯河水，省的看了心烦！

作者: ilwmin 时间: 2011-11-11 13:55
楼主这心胸够宽广的

作者: egametang 时间: 2011-11-11 14:01
用C++的朋友哪个不会C?反而是一帮不会C++的C程序员天天在攻击C++，这算什么事……

作者: zylthinking 时间: 2011-11-11 14:05

用C++的朋友哪个不会C?反而是一帮不会C++的C程序员天天在攻击C++，这算什么事……
egametang 发表于 2011-11-11 14:01

屁话

作者: 留痕之雁 时间: 2011-11-11 14:09
{:3_193:}{:3_193:}不支持，不反对。
本是同根生，相煎何太急！

互相学习很有益处。

作者: egametang 时间: 2011-11-11 14:12

不支持，不反对。
本是同根生，相煎何太急！

互相学习很有益处。
留痕之雁发表于 2011-11-11 14:09

关键是变成Cer对C++的单向攻击了

作者: pandaiam 时间: 2011-11-11 14:23
强烈支持。

作者: egametang 时间: 2011-11-11 14:26

强烈支持。
pandaiam 发表于 2011-11-11 14:23

多谢兄弟支持！熟话说，惹不起我还躲不起吗？开个新版我们C++er自己玩还不行吗？

作者: 群雄逐鹿中原 时间: 2011-11-11 14:39

用C++的朋友哪个不会C?反而是一帮不会C++的C程序员天天在攻击C++，这算什么事……
egametang 发表于 2011-11-11 14:01

这个倒是！

不会C++的攻击C++
不会java的攻击java

作者: pandaiam 时间: 2011-11-11 14:42

多谢兄弟支持！熟话说，惹不起我还躲不起吗？开个新版我们C++er自己玩还不行吗？
egametang 发表于 2011-11-11 14:26

对不起，我智商低，只能玩c。。

作者: btdm123 时间: 2011-11-11 14:44
支持，我认为C++的普通企业应用远不如java，一般主要做图形界面和游戏，但和C的用途已经截然不同，C只用来做底层开发，话不投机阿

作者: bruceteen 时间: 2011-11-11 14:57
本帖最后由 bruceteen 于 2011-11-11 15:24 编辑

楼主心胸要开阔点
1。“我只用C”的意思是说即使用C++，也可以不用异常的
2。关于这一条，我同意你的观点
3。面向对象本来就是无用的
面向对象在十多年就被证明是用途极度有限的一个小技巧，虽然当年寄予人们以希望，恰如烟花，吓人一跳，但顷刻间屁都不剩一个，这不是一个两个人的观点，而是全世界，当然不包括“小学生”，因为这是两个截然不同的世界。不要把C++看成是面向对象的语言，C++早声明未来也不会再在不堪大用的面向对象上浪费任何精力。

另外，面向对象 != 基于对象，就像加了辣椒的面包 != 面包，因为不是所有人都喜欢辣椒。特意提这个，仅是先滤掉一些连面向对象都不懂的人拿基于对象来反驳我。

作者: egametang 时间: 2011-11-11 15:08

楼主心胸要开阔点
1。“我只用C”的意思是说即使用C++，也可以不用异常的
2。关于这一条，我同意你的观点 ...
bruceteen 发表于 2011-11-11 14:57

是的，C也可以写出基于对象的代码，C++面向对象不过是些语法糖，
但并不说明C++面向对象的语法糖就是无用的，恰恰想反，有了这些语法糖，
用C1000行写出的代码，用C++200行就搞定了，代码写的更加优美，可读性更高，
进而保证了代码的正确性。
可以说C语言也不过是汇编语言的语法糖，你能说C语言无用吗？
编译器本来就是帮人去简化这些操作，不是吗？

作者: oooooxxxxx 时间: 2011-11-11 15:19
咆哮个毛啊，写了两行吸夹夹就了不起，连别人不喜欢异常都受不了
大家都是嘴炮，谁比谁高级多少啊，要显示优越性就拿出硬货来，咆哮有毛用，你要说你遇到的ooxx场景或者某开源程序的神马异常神马OO多么牛鼻，那能看懂的继续嘴炮看不懂的退散，你毛都拿不出来，光声音大了不起啊。

作者: bruceteen 时间: 2011-11-11 15:22

是的，C也可以写出基于对象的代码，C++面向对象不过是些语法糖，
但并不说明C++面向对象的语法糖 ...
egametang 发表于 2011-11-11 15:08

我想表达的观点是：面向对象属于鸡肋，它其实已经被C++放弃了，虽然没有赶出家门，但已经任其自生自灭
我个人的观点是：即便面向对象是光辉照人，能力超群的，它本身也是很浅白简单的，就像呼吸空气一样，虽然能呼吸空气是非常重要的，但掌握此技能没必要骄傲，因为它不比喝水吃饭等同样重要的技能更难掌握。何况面向对象啥也不是呐！

作者: egametang 时间: 2011-11-11 15:26

咆哮个毛啊，写了两行吸夹夹就了不起，连别人不喜欢异常都受不了
大家都是嘴炮，谁比谁高级多少啊，要显示 ...
oooooxxxxx 发表于 2011-11-11 15:19

我非常喜欢同C++er讨论异常的好坏，但请C程序员不要跑进来说，
我只用C，不喜欢异常，然后举出异常的坏处（通常是不值得一驳的理由）
要批评一个东西，至少要先了解它吧！要批评C++也要十分懂C++吧，至少也要用一用吧！

作者: egametang 时间: 2011-11-11 15:33

我想表达的观点是：面向对象属于鸡肋，它其实已经被C++放弃了，虽然没有赶出家门，但已经任其自生自灭
我 ...
bruceteen 发表于 2011-11-11 15:22

这里不存在骄傲的问题，大家都是码农，不存在骄傲。这里要表达的观点是，
批评C++要了解C++，但现在C/C++版，大量的Cer胡乱攻击C++，这是广大C++同胞无法容忍的！

作者: w_anthony 时间: 2011-11-11 15:42
如果那个有垃圾回收机制的C1X编译器出来了，我等C++er不知道会怎么面对这个东西……

作者: bruceteen 时间: 2011-11-11 15:55

这里不存在骄傲的问题，大家都是码农，不存在骄傲。这里要表达的观点是，
批评C++要了解C++，但 ...
egametang 发表于 2011-11-11 15:33

我理解你的想法，但对于“批评C++要了解C++”这个观点我不是很认同
1。对“了解”作“掌握”解，那么什么程度的掌握才是“了解”
2。对“了解”作“理解”解，那么正是因为不可以理解才批评
3。批评C++只需要了解一点就行了，未必需要全部了解，除非你想杀对方一个鸡犬不留。比如Java说面向对象，那可以从面向对象上插它；说二进制跨平台，那可以从二进制跨平台上捅它；说当年语法简陋，那可以从现在语法的繁杂上爆它

对于 C 和 C++ 的优劣，我个人觉得
C美，像一只猴子，结构简洁而精密，体态流畅，肌肉匀称，就是骨骼小了点
C++强，像一只熊，力量强大，但肥嘟嘟的
所以工作中，我一般选C++，因为它强大呗，但一直梦想着这只熊能够去健身房练出完美体型来，去掉多余的赘肉，或那只猴子能够多吃点早日变成威猛的大金刚

作者: btdm123 时间: 2011-11-11 15:57
回复 19# bruceteen

你说的是objc?

作者: bruceteen 时间: 2011-11-11 16:12

如果那个有垃圾回收机制的C1X编译器出来了，我等C++er不知道会怎么面对这个东西……
w_anthony 发表于 2011-11-11 15:42

垃圾回收有时是有用的，这一点我承认，但要在C++语法上加上这个功能，我觉得实在是……，
我一个朋友喜欢抠臭脚，但开车时怎么办？他在左脚下放了个铁杆，一边开车一边用脚去蹭，爽是爽了，但还是有点麻烦，且不美观。有次，他开玩笑对我说，应该强制规定所有汽车左脚旁都焊一根铁杆，那样就方便多了。
在C++中，我几乎都不记得有用new的地方了。首先，需要手工动态分配内存的需求本来就不多，必须要的场合下，一般那些std容器比自己管理更方便。
所以说，如果一定要为了那些喜欢new着玩的变态，或偶尔几次正常的new，而引入庞大的，颠覆性的垃圾回收机制，实在比抠脚丫更令人恶心

作者: asuka2001 时间: 2011-11-11 16:22
本帖最后由 asuka2001 于 2011-11-11 16:24 编辑

C++有，你不一定要用，你认为任何C++的组成部分不满足需求，直接不用就是了。

我喜欢C/C++的理由：从不限制你做你想做的事!

你不想用是你的自由，但是你不能阻止别人希望使用的自由！

作者: bruceteen 时间: 2011-11-11 16:23

回复 bruceteen

你说的是objc?
btdm123 发表于 2011-11-11 15:57

^_^ 开玩笑的吧，objc像我所在公司的一个顾问，他一直觉得他掌握的知识点（文化大**时期在农村大学学来的，早就风干化成灰了）是最重要最高深的，只要我们虚心学习，能让全人类科技加速一百年。

作者: egametang 时间: 2011-11-11 16:24

我理解你的想法，但对于“批评C++要了解C++”这个观点我不是很认同
1。对“了解”作“掌握”解，那么什么 ...
bruceteen 发表于 2011-11-11 15:55

任何东西有利有弊，批评弊端一定要明白有利的一面，这样才能说了解
例如C++模版，这东西在自己项目中胡乱使用，弊端很大，用的不好，代码难以读懂。难以调试
但是做成类库就不一样了，我们无需关心他怎么实现就可以方便的使用。
难道因为一些弊端就放弃它吗？

多余的赘肉完全可以自己去除，例如google code style就是干这种事的。
甚至google 提供了 cpplint工具，我们可以集成至svn，检查不通过不能提交

作者: bruceteen 时间: 2011-11-11 16:28

... 例如google code style ...
egametang 发表于 2011-11-11 16:24

google code style 是最符合我原本风格的，但如果要让它变成一个绳索，还不如毁了它

作者: egametang 时间: 2011-11-11 16:39

google code style 是最符合我原本风格的，但如果要让它变成一个绳索，还不如毁了它
bruceteen 发表于 2011-11-11 16:28

每个人每个团队的编码风格是不一样的，google不使用异常，不等于说微软也不使用
难道google code style建议不使用就要从标准中把它去掉吗？
即使是google也认为异常是很有用的，只不过为了兼容以前的代码妥协了而已
当然如果没有一个人用，这个语法点就是要去除掉，很明显这是不可能的。

作者: w_anthony 时间: 2011-11-11 17:08

垃圾回收有时是有用的，这一点我承认，但要在C++语法上加上这个功能，我觉得实在是……，
我一个朋友 ...
bruceteen 发表于 2011-11-11 16:12

vector还是不能替代new和malloc，vector要求元素必须有拷贝构造。另外有时候轻量的应用也未必需要它出场。内置类型的“vector+连续的resize”还是不如“malloc+realloc”实惠。

C++有，你不一定要用，你认为任何C++的组成部分不满足需求，直接不用就是了。

我喜欢C/C++的理由：从不限 ...
asuka2001 发表于 2011-11-11 16:22

但是C1X出来以后，难保很多人不会去用那个垃圾回收，然后你会发现看他的代码，你会比较郁闷。
就像我现在看到一堆boost+bind的时候会比较头痛（目前我只停留在stl的程度上）。我相信Cer看C++头痛很大程度上也是因为stl和boost存在的缘故。
虽然有些功能你可以不用，就像Cer用C++编译器一样可以写C并且编译C代码，但是如果成为标准以后，你可能不得不去学那些东西，而实际上这么多年没这东西你一样过得很滋润，于是你就可能会认为，那些新增的东西都是多余的，并且极力的排斥它。

作者: egametang 时间: 2011-11-11 17:21

vector还是不能替代new和malloc，vector要求元素必须有拷贝构造。另外有时候轻量的应用也未必需要它出场 ...
w_anthony 发表于 2011-11-11 17:08

一句boost fuction bind是类型安全的函数指针
c语言用函数指针，类型不安全，十分容易出错，而且无法绑定变量，
不可同日而语！是愿意长痛还是愿意短痛呢？

作者: zylthinking 时间: 2011-11-11 17:26
不停止生搬硬套上新特性的语言，迟早会崩溃；个人感觉。
说白了，不就是那个 CA 冠群的发展路线么

作者: btdm123 时间: 2011-11-11 17:26

^_^ 开玩笑的吧，objc像我所在公司的一个顾问，他一直觉得他掌握的知识点（文化大**时期在农村大 ...
bruceteen 发表于 2011-11-11 16:23

苹果的人可不这么想哦

作者: zylthinking 时间: 2011-11-11 17:29

苹果的人可不这么想哦
btdm123 发表于 2011-11-11 17:26

奶奶的刚发现， IOS 5中 BSD socket 貌似彻底挂了，原来还有办法在后台继续连接，现在彻底玩完了。
狗日的，想骂人

作者: X-Hawk 时间: 2011-11-11 17:41
用什么是迫不得已的。

可以选择的话，我选javascript.

作者: w_anthony 时间: 2011-11-11 17:53
本帖最后由 w_anthony 于 2011-11-11 17:56 编辑

一句boost fuction bind是类型安全的函数指针
c语言用函数指针，类型不安全，十分容易出错，而 ...
egametang 发表于 2011-11-11 17:21

C的使用者连指针（函数指针也是指针）都驾驭不了的话，还用什么C？难道这世上不存在自身“错误”地使用boost fuction bind而导致挂掉的人？难道不存在错误使用vector而挂掉的人？
boost的函数绑定只是一个形式，并不是真正的函数指针。你试试给“参数是回调函数的API”绑定个变量试试！？实际上这点boost根本就无法做到，但是偏偏遇到过很多不知其本质的人总想这么做，自己没试过却误以为可以，并诱导其他人使用boost。

如果空有其“形”也算优点的话，那实际上C++也可以支持函数返回值重载。
比如func这个函数
int i = func(param);
float f = func(param);
可以是两个函数，因为func其实是这么个玩意儿：
class func
{
public:
func(...) {};
operator int() { ... };
operator float() { ... };
};
而这个func你是无论如何也弄不成函数指针的……

作者: egametang 时间: 2011-11-11 18:02
本帖最后由 egametang 于 2011-11-11 18:03 编辑

C的使用者连指针（函数指针也是指针）都驾驭不了的话，还用什么C？难道这世上不存在自身“错误”地使用 ...
w_anthony 发表于 2011-11-11 17:53

class ThreadPool: private boost::noncopyable
{
private:
int threadNum;
boost::detail::atomic_count workNum;
volatile bool running;
boost::mutex mutex;
boost::condition_variable cond;
boost::condition_variable done;
std::list<ThreadPtr> threads;
std::list<boost::function<void (void)> > tasks;

void Runner();
public:
ThreadPool(int num = 0);
virtual ~ThreadPool();

virtual void Wait();
virtual bool Schedule(boost::function<void (void)> task);
};

一个线程池类
怎么使用呢？
void Max(int a, int b, int* z)
{
*z = a > b? a : b;
}
thread_pool.Schedule(boost::bind(&Max, x, y, &z));
简简单单一句话，把一个任务扔到了线程池里面，并且是类型安全的哦

我这里Schedule参数就是函数指针哦

C语言用指针，传参是void的，结果还得类型转换，你说麻不麻烦？

作者: fender0107401 时间: 2011-11-11 18:04

作者: w_anthony 时间: 2011-11-11 18:04
有时候bind一下确实不错，不过通篇bind，我确实很头疼。我还是比较倾向于C的C++er，所以看到太倾向于C++的代码时，我承认我难免脑子不够用。所以说C1X这个更庞大的东西出来的时候该怎么面对啊……

作者: 幻の上帝 时间: 2011-11-11 18:05
回复 26# egametang

真是有可能的。
ISO C++03的export，因为没人用（M$和GNU等大部分厂商甚至都不愿意实现它），直接在ISO C++11被X了，连deprecated都没有（虽然我觉得像register这类被deprecated也就是凑数使ISO C++ Annex的条目编号尽可能变化少能照顾标准的兼容性而已）。

作者: 幻の上帝 时间: 2011-11-11 18:08
回复 28# egametang

短痛是把C/C++一起干掉。谁叫C++想兼容C。

模版之类的许多复杂性就语义来说本来不必要，存在的合理性是因为要给兼容于C的拼凑起来的静态类型系统擦屁股。

作者: egametang 时间: 2011-11-11 18:09

C的使用者连指针（函数指针也是指针）都驾驭不了的话，还用什么C？难道这世上不存在自身“错误”地使用 ...
w_anthony 发表于 2011-11-11 17:53

你的思维已经被C语言固定主了，既然用了c++，我就不需要函数指针了，
boost::function就是C++里面的函数指针，
我还用的着写 void (*f)()之类的指针吗？
boost::function<void (void)> func 不比 void (*f)() 好？
请看我上面的例子

作者: 幻の上帝 时间: 2011-11-11 18:22
回复 14# oooooxxxxx

喜不喜欢异常无所谓。但受不了“连别人不喜欢异常都受不了”的口气。在语言层面上，异常提供的机制是不用异常无可替代的。你可以因为不喜欢或者用不到等等理由而不用，这是你自己的事情；但是以自己的习惯妄自揣测他人并贬低某种与己无关（至少对方看起来是这样）的东西存在的必要性，叫我肿么吐槽好呢。
至于“毛”，真不用拿什么出来。要举极端情况的话，从用户角度来看禁止异常和goto无用论类似（语言实现角度倒是相反）。如果想像不到，只能说明这方面彻底外行了，看热闹就行，歪楼又能歪到哪去呢。既然是你自己拒绝去弄懂的东西，别人也没义务包你清楚。

作者: 三月廿七 时间: 2011-11-11 18:27
本帖最后由三月廿七于 2011-11-11 18:29 编辑

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

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

作者: 幻の上帝 时间: 2011-11-11 18:29
回复 39# egametang

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

作者: linccn 时间: 2011-11-11 20:06
回复 15# bruceteen

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

给个出处吧

作者: wait_rabbit 时间: 2011-11-11 20:17

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

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

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

作者: egametang 时间: 2011-11-11 20:58

回复 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 时间: 2011-11-11 21:22
本帖最后由 w_anthony 于 2011-11-11 21:46 编辑

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 时间: 2011-11-11 21:33

回复 bruceteen

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

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

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

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

个人愚见，别轰我

作者: egametang 时间: 2011-11-12 00:06

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

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

作者: w_anthony 时间: 2011-11-12 00:55

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……

作者: x5miao 时间: 2011-11-12 01:22
分吧

作者: fallening 时间: 2011-11-12 02:24

C++ 11 除了那个转移语义还行（其实只是为了修复语言bug）之外，其他的对我而言意义不大，加重编译器负担， ...
ah13k 发表于 2011-11-11 22:19

不止这些的
Variadic Template 有了之后，写类库相当方便，boost 也想必会大幅简化
thread/atomic 尤其是 future 非常难得
也有很多是早就应该有了的，现在才加进去，比如 regex，tuple，smartptr, hash_map

作者: oooooxxxxx 时间: 2011-11-12 04:41

回复 oooooxxxxx

喜不喜欢异常无所谓。但受不了“连别人不喜欢异常都受不了”的口气。在语言层面上，异 ...
幻の上帝发表于 2011-11-11 18:22

不就是嘴炮麼……嘴炮都上火，出息啊

作者: pmerofc 时间: 2011-11-12 10:14
提示: 作者被禁止或删除内容自动屏蔽

作者: 幻の上帝 时间: 2011-11-12 12:19
回复 53# oooooxxxxx

我是呼吁嘴炮要有营养。

作者: 幻の上帝 时间: 2011-11-12 12:22
回复 45# egametang

编译时间对你可能不是问题，对我可能是大问题……穷搓矮机器烂没办法

别完全无视第二条嘛喂……function放容器里面去重什么的。。。试试就知道。

作者: 幻の上帝 时间: 2011-11-12 12:25
回复 50# w_anthony

回调……boost.signal吗。。感觉太重量级了。

作者: fallening 时间: 2011-11-12 13:00

回复 w_anthony

回调……boost.signal吗。。感觉太重量级了。
幻の上帝发表于 2011-11-12 12:25

用 C++ 可以写得很轻松，大概两百多行就可以自己造一个轮子，跟 boost::signal 差不多

我无聊的时候写过一个： https://github.com/fengwang/signal0x

作者: 幻の上帝 时间: 2011-11-12 13:21
回复 58# fallening

看起来是不错，不过不发明轮子却总是造轮子也不行啊。
boost.signal是抽象层次太多裁剪起来很累，你这个好像又有些不够灵活的地方。
比方说我不需要priority呢？我需要改变 priority_connection_subscriber_type呢？利用你的代码，只能在无视和改变实现之一选择吗？
（好吧，可能是我要求太高了……用C++总是有明明知道如何优化但因为不得不改变现有代码导致维护问题而只能作废的无力感……）

作者: reiase 时间: 2011-11-12 13:55
C++的传统是吹个NB，把你套进去然后宣布：那个NB太搓了，俺们已经不屑于那个NB了

比如面向对象，各种使用链表作对象的语言，都很优雅和简单，唯独C++那个基于内存布局和虚函数表的面向对象实现恶心的要命。本来简洁优雅的OO规则，经过内存布局等方面的限制，加入大量硬规则后就变得不堪入目了。

再比如异常，C++的异常貌似都没存在的必要，很多优秀的C++库压根就没理C++异常。无非是让代码分支去处理错误嘛。分支有if，栈上回滚有return，为毛要异常。“异常非常NB，能够处理XX、XX、XX和XX，不过XX，XX，XX情况下一定不要用异常，否则XX、XX、XX“

lambda是最让人失望的特性了，本以为可以在线生成回调函数，结果发现lambda表达式生成的是函数对象，根本不能转换成函数指针。说实话，还不如scipy里边的weave好用，我内嵌一段C代码，weave负责为这段代码生成一个唯一的函数名并编译，然后直接在Python里调用。100%的C函数，当回调完全没问题。

最近看一些算法的东西，发现面向对象之所以流行，只不过因为把数据放对象里是一种比较安全的”全局变量“。有些人死活想不明白怎么管理变量的生命周期，以及如何减少函数调用时的”按值传递“。好吧，写个对象，然后数据塞里边就不用传了

作者: fallening 时间: 2011-11-12 14:30
本帖最后由 fallening 于 2011-11-12 14:34 编辑

回复 fallening

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

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

作者: songvar 时间: 2011-11-12 14:31
C++用惯了，倒是觉得C的面向对象很简陋，很搓澡，很难看

作者: James_think 时间: 2011-11-12 16:40

作者: btdm123 时间: 2011-11-12 16:47
分出去好，实际上是两种语言了

作者: sonicling 时间: 2011-11-12 19:47
本帖最后由 sonicling 于 2011-11-12 20:05 编辑

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语言支持所谓的“面向对象”，的确很蛋疼。）面向对象之所以能流行，是因为它的确可以提高软件的可扩展性和可维护性。如果这两个特性并不是你的软件的主要考量，那么就不要在喝汤的时候说叉子不好用，兜汤请用瓢。

作者: 幻の上帝 时间: 2011-11-12 20:15
回复 61# fallening

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

作者: 幻の上帝 时间: 2011-11-12 20:23
回复 65# sonicling

面向对象作为方法论是指“可以这么理解”，最大的意义就是在于建模的过程中提供一套可能使人容易理解抽象的手段。降低对象间的耦合度是之后更细化的手段的任务了。
如果光面向对象就能解决这个问题，面向接口又算什么？
我认为面向对象的流行主要原因是给用户降低抽象问题域的难度的某种自由（或者说，对全面理解问题这方面的智商的要求比较低

）。一个设计者可以不必了解整个任务而设计其中的一部分，用面向对象的协议来和其它设计者协调以便实现他的设计。这对软件工业来说有益于节约成本，但设计的总体质量未必能更好。话说要是都只知道鼓吹纯面向对象，那么这个领域的平均智商会到什么层次呢……

作者: sonicling 时间: 2011-11-12 22:47
本帖最后由 sonicling 于 2011-11-12 22:49 编辑

回复 67# 幻の上帝

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

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

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

作者: shang2010 时间: 2011-11-13 07:22
{:2_169:}

作者: reiase 时间: 2011-11-13 14:03
回复 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++的语言特性了吗？

作者: egametang 时间: 2011-11-14 00:02

回复 sonicling

我觉得内存布局无关的OO才是好OO，才可能简洁优雅地实现OO。你也承认C++的OO实现地有 ...
reiase 发表于 2011-11-13 14:03

java就不需要自己释放资源吗？
try
{
}
catch
{
}
finally
{
}
这个finally就是要自己施放的哦
相比来说c++确定性析构比java语法好看多了~~

作者: waily 时间: 2011-11-14 10:03
回复 1# egametang

强烈支持！

作者: 幻の上帝 时间: 2011-11-14 11:03
回复 70# reiase

用Java就不用理解语义？javac已经智能到能帮你脑补代码的程度了么？

语言特性可以用来支持OO的实现，但OO从来就不是什么语言特性。就算鼓吹所谓纯OO的Java之类，看来也不敢说Java的哪些特性就等于OO。

作者: hbxfzzq_hm 时间: 2011-11-14 11:23

不支持，不反对。
本是同根生，相煎何太急！

互相学习很有益处。
留痕之雁发表于 2011-11-11 14:09

本是同根生，相煎何太急！不错

作者: chinesedragon 时间: 2011-11-14 13:28
ksks呵呵

作者: zhw_yihui 时间: 2011-11-14 14:10

作者: lexken 时间: 2011-11-14 14:12

1.讨论异常时，一帮人说，我只用C……(你用C跑来讨论干嘛？)
2.c++没开发出大型软件……(眼睛长在屁股上吗 ...
egametang 发表于 2011-11-11 13:47

支持

作者: nizvoo 时间: 2011-11-14 17:18
都是赴云

作者: walleeee 时间: 2011-11-14 20:39
赞同！特别是现在新的c++11出来了，问题更是混杂麻烦，建议分出c++版块

作者: oooooxxxxx 时间: 2011-11-15 02:49
回复 55# 幻の上帝

很简单阿，要营养就要硬货，光有论点，没有论据哪里有营养。

作者: castle_breeze 时间: 2011-11-15 22:42
刚注册号，看到的尽是一片叫骂声，失落。

作者: castle_breeze 时间: 2011-11-15 22:43
刚注册号，看到的尽是一片叫骂声，失落。

作者: GFree_Wind 时间: 2011-11-15 23:01
回复 3# egametang

太小瞧C了吧。虽然C++的语法繁杂，个人认为C++没有10年别说自己精通。
但是C也没那么容易，至少没有5年的好好研究，也别说会C。

无意攻击，只是看到这么轻视C，感觉有些不忿。
C++我也了解一些，至少经典的C++的书籍基本都看过，不敢说会，只能说了解一些。

希望不要轻视C语言。

作者: digdeep126 时间: 2011-11-15 23:22

C++ 11 除了那个转移语义还行（其实只是为了修复语言bug）之外，其他的对我而言意义不大，加重编译器负担， ...
ah13k 发表于 2011-11-11 22:19

提供的多线程支持，也很重要。http://en.cppreference.com/w/cpp

作者: zyzbill 时间: 2011-11-16 08:06
我多么希望国内也有类似http://stackoverflow.com/这样的网站啊，可惜CSDN, ChinaUnix bbs几十年都不变, 这些论坛技术挺落后的。

作者: king_819 时间: 2011-11-16 10:14
不管什么语言，开发出来的项目能创造利润、减少成本这才是关键，没必要针对一种语言进行攻击！！

作者: king_819 时间: 2011-11-16 10:29

我多么希望国内也有类似这样的网站啊，可惜CSDN, ChinaUnix bbs几十年都不变, 这些论坛技术挺落后的。
zyzbill 发表于 2011-11-16 08:06

还是分的不够细，CU里面移动开发关注的不够多，现在的移动开发火的一塌糊涂了

作者: sep 时间: 2011-11-16 10:44

还是分的不够细，CU里面移动开发关注的不够多，现在的移动开发火的一塌糊涂了
king_819 发表于 2011-11-16 10:29

是啊，挺讽刺的。移动开发是未来重中之重，CU却没有一个拿得出手的板块。

作者: king_819 时间: 2011-11-16 10:47

是啊，挺讽刺的。移动开发是未来重中之重，CU却没有一个拿得出手的板块。
sep 发表于 2011-11-16 10:44

CU要与时俱进了！

作者: btdm123 时间: 2011-11-16 11:05
真的应该分离，用C和C++的场景是完全不一样的，C适合unixy的设计，简单，模块分离，正交，C++其实更适合windows平台，功能大而全，复杂

作者: Aquester 时间: 2011-11-16 12:53
顶，这个建议好，两者差异还是蛮大的，C++远比复杂，而一些C牛人不是不屑C++的，实际都是些没有体验到C++乐趣和伟大的人。

作者: egametang 时间: 2011-11-16 13:06
你们看看，又出来这种论调了……

http://bbs.chinaunix.net/thread-3618853-5-1.html

作者: zhangrui01 时间: 2011-11-16 13:30
楼主这胸怀可以成诺亚方舟了我顶

作者: lenky0401 时间: 2011-11-16 14:21
每一种语言都有其优缺点通过争议或者说互爆并了解它们各自的缺点能帮助在我们将来面临不同业务选择不同语言时做成自己正确选择这也是我没有对C版里这些帖子做管理的原因但是如果只看到了各位网友文字表现的争吵和怒气没看到其中提到的事实恐怕难以学到各自合理并且优秀的论点

作者: pitonas 时间: 2011-11-17 01:57
我只用C

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)