y**b 发帖数: 10166 | | n******t 发帖数: 4406 | 2 如果就打算推这个, C++肯定就挂了。
这么个四不像,怎么玩啊?
【在 y**b 的大作中提到】 : http://blog.csdn.net/doctorsc/article/details/6777849 : http://sd.csdn.net/a/20111114/307392.html : “C++11就像一门新的语言。” - Bjarne Stroustrup : 好是好,够折腾的。
| t****t 发帖数: 6806 | 3 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不
过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度,
还有auto以及range based for, 比如说原来遍历容器需要写:
for (vector::iterator i=c.begin(); i!=c.end(); ++i) {
/* do something to *i */
}
现在可以写:
for (auto i: c) {
/* do something to i */
}
【在 n******t 的大作中提到】 : 如果就打算推这个, C++肯定就挂了。 : 这么个四不像,怎么玩啊?
| A**u 发帖数: 2458 | 4 有点丧失了清晰性..
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| t****t 发帖数: 6806 | 5 我觉得正好相反, 程序变得更清晰更易读了.
【在 A**u 的大作中提到】 : 有点丧失了清晰性..
| y**b 发帖数: 10166 | 6 boost里面的智能指针,分门别类好多种,头大。
c++11搞了两种,是否能一劳永逸解决问题呢,不能的话,
没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
【在 y**b 的大作中提到】 : http://blog.csdn.net/doctorsc/article/details/6777849 : http://sd.csdn.net/a/20111114/307392.html : “C++11就像一门新的语言。” - Bjarne Stroustrup : 好是好,够折腾的。
| h*c 发帖数: 1859 | 7 C++11好像引入了好多关键字。。。
不喜
不过nullptr还是不错的,以前用NULL, BS用0,0是很不好的一个东西啊
【在 y**b 的大作中提到】 : boost里面的智能指针,分门别类好多种,头大。 : c++11搞了两种,是否能一劳永逸解决问题呢,不能的话, : 没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
| t****t 发帖数: 6806 | 8 你说说哪个新关键字让你觉得头疼了?
【在 h*c 的大作中提到】 : C++11好像引入了好多关键字。。。 : 不喜 : 不过nullptr还是不错的,以前用NULL, BS用0,0是很不好的一个东西啊
| s****a 发帖数: 238 | 9 至少lambda函数就很实用,以前为了实现类似的功能很头疼。
它的线程库不知道怎么样。关键是这些新特性基本是独立的,完全可以慢慢过渡 | w***g 发帖数: 5958 | 10 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高
下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。
2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。
除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
【在 t****t 的大作中提到】 : 你说说哪个新关键字让你觉得头疼了?
| | | t****t 发帖数: 6806 | 11 constexpr我也确实不是很喜欢, 感觉为优化而优化了, 还不如引入var-size array呢.
nullptr我倒觉得没什么, 从一致性的角度来说, NULL这样的大写习惯上是macro, 不合
适成为关键字.
auto我觉得没问题, 多写写就清楚了:)
【在 w***g 的大作中提到】 : 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高 : 下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。 : 2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。 : 除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
| D*******a 发帖数: 3688 | 12 about auto: you may just keep (ab)using it until the compiler squeals!
hiahia
【在 w***g 的大作中提到】 : 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高 : 下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。 : 2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。 : 除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
| n******t 发帖数: 4406 | 13 这个算syntax sugar把,我觉得属于可有可无的东西,variadic template C很多C编译
器里面也有类似的的扩展。不过我觉得一个东西有用,不一定要放到 standard里面,反
而对语言推广不利。
还有我觉得没必要把thread弄成语言的组成部分,用平台上的库就好了。
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| t****t 发帖数: 6806 | 14 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也
可以写出所有的程序对吧
但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前,
tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的
case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也
快, 对性能也没影响.
好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平
台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面,
正是为了语言的推广.
,反
【在 n******t 的大作中提到】 : 这个算syntax sugar把,我觉得属于可有可无的东西,variadic template C很多C编译 : 器里面也有类似的的扩展。不过我觉得一个东西有用,不一定要放到 standard里面,反 : 而对语言推广不利。 : 还有我觉得没必要把thread弄成语言的组成部分,用平台上的库就好了。
| d***q 发帖数: 1119 | 15
auto比较好,能省很多事.
不过用 var 可能还好,还能省掉一个字母。
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| d***q 发帖数: 1119 | 16
我用的最多的只有 shared_ptr
【在 y**b 的大作中提到】 : boost里面的智能指针,分门别类好多种,头大。 : c++11搞了两种,是否能一劳永逸解决问题呢,不能的话, : 没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
| t****t 发帖数: 6806 | 17 do not introduce new keyword unless necessary. auto was almost useless, it's
good to assign a new meaning.
【在 d***q 的大作中提到】 : : 我用的最多的只有 shared_ptr
| d***q 发帖数: 1119 | 18
面,
如果按照 可有可无的说法,很多语言都没有必要存在了。
语法糖很多时候就是差别的来源。喜不喜欢和个人偏好有很大关系。
【在 t****t 的大作中提到】 : 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也 : 可以写出所有的程序对吧 : 但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前, : tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的 : case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也 : 快, 对性能也没影响. : 好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平 : 台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面, : 正是为了语言的推广. :
| t****t 发帖数: 6806 | 19 if i am correct, shared_ptr is the default behaviour of java except GC is
performed immediately. so it's natural that shared_ptr is used the most.
auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr
will becomes useful. current gcc implementation is not as good as
shared_ptr though, for example if T is incomplete, you may experience
problem with instantiating dtor and move (which includes move ctor and move
assignment).
【在 d***q 的大作中提到】 : : 面, : 如果按照 可有可无的说法,很多语言都没有必要存在了。 : 语法糖很多时候就是差别的来源。喜不喜欢和个人偏好有很大关系。
| X****r 发帖数: 3557 | 20 I don't think Java (precisely, any particular JVM) uses reference
counting for pointers.
move
【在 t****t 的大作中提到】 : if i am correct, shared_ptr is the default behaviour of java except GC is : performed immediately. so it's natural that shared_ptr is used the most. : auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr : will becomes useful. current gcc implementation is not as good as : shared_ptr though, for example if T is incomplete, you may experience : problem with instantiating dtor and move (which includes move ctor and move : assignment).
| | | g*****g 发帖数: 34805 | 21 Of course not, reference couting cannot reclaim cyclic structure.
Most GC algorithms are tracing collectors.
【在 X****r 的大作中提到】 : I don't think Java (precisely, any particular JVM) uses reference : counting for pointers. : : move
| d***q 发帖数: 1119 | 22
move
当然 偶尔也要用 weak_ptr。
解决一些 例如 Parent { Child* children}
Child {Parent* p} 之类的问题。
cycle reference是 引数法的缺陷。 不过实际上我很少会在需要c++的场合使用这种设
计。
原来std带的那个 auto_ptr是太蠢了点。难怪没人愿意用。
【在 t****t 的大作中提到】 : if i am correct, shared_ptr is the default behaviour of java except GC is : performed immediately. so it's natural that shared_ptr is used the most. : auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr : will becomes useful. current gcc implementation is not as good as : shared_ptr though, for example if T is incomplete, you may experience : problem with instantiating dtor and move (which includes move ctor and move : assignment).
| t****t 发帖数: 6806 | 23 oh...那我土了.
【在 X****r 的大作中提到】 : I don't think Java (precisely, any particular JVM) uses reference : counting for pointers. : : move
| L***n 发帖数: 6727 | 24 受教了
【在 g*****g 的大作中提到】 : Of course not, reference couting cannot reclaim cyclic structure. : Most GC algorithms are tracing collectors.
| n******t 发帖数: 4406 | 25 我觉得这种invention是没边的。。什么功能都想弄出来,最后就是杂和乱。当然我最近
很长一段时间可能做系统开发比较多,看法不一定全面。
variadic template貌似是从C99里面抄过来的? 而且其实C99里面加的新功能其实比起C
++来说保守太多了,而且都是放到标准里面有不少需求的特性,结果其实际上大部分稍
微考虑一点移植性的程序都不太用C99的新功能。
至于thread,跨平台的idea固然是没有问题的,但是就这个case来说,在C++里面弄出这
么一个内建的功能,比起调用pthread库来说,有什么好处?我的感觉除了麻烦,没有好
处。移植性?pthread在所有UNIX和Windows上都有实现,而等到C11在所有平台上都有良
好支持恐怕更慢。C++的thread有pthread不能完成的事情么,就我所知没有,反过来呢
?一定是有的。加入这么个东西,首先不支持C11的编译器就出问题了,如果还没有别的
好处,程序员为什么要用?
我个人的感觉编程打字不是瓶颈,也就是说,如果一个功能推出只是为了少打几个字,
意义不是很大。当然有些时候,简化了句法,同时也简化了思路。但是对于C++来说,我
觉得it从来么有真正做到像java那样的封装程度,也就是说你可以用auto,但是你脑子里
面如果不知道那东西其实是个iterator的话,你很快就会发现你没法真正写稍微大点的
项目,同样iterator你如果对实现没有比较清楚的了解,你一样很快就会撞到让你非常
困惑的问题。从这个角度来数,perl的精简是真正的精简,而C++的这种我觉得只是少打
一些字而已。
面,
【在 t****t 的大作中提到】 : 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也 : 可以写出所有的程序对吧 : 但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前, : tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的 : case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也 : 快, 对性能也没影响. : 好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平 : 台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面, : 正是为了语言的推广. :
| t****t 发帖数: 6806 | 26 新语言标准刚出现肯定会有移植性的问题, 不管你加什么都一样, 因为编译器实现新标
准必定有先有后. 如果从这个角度来看问题, 那就真的什么都不要加了, 永远不变最好
了. perl 5.8出来很长时间后我还能看到check 5.003的程序.
这个滞后性是永远没法避免的. jdk1.2 - 1.5中间搞了多少麻烦? 我不用java, 但是我
也听说过. 语言总要发展的, 如果没有标准化的话, 那就没人控制朝哪个方向发展. 标
准化正是为了避免以后更多的麻烦.
variadic template和C99没关系, 你记错了. 你想说的是variadic macro吧, 那个在c+
+11里确实有了. tuple还是一个很有用的类, 有了variadic template才方便支持的.
thread在unix和windows上还是有很大不同吧. 我windows不熟, 但是我记得win32的调
用应该和pthread并不兼容. 当然肯定有pthread wrapper, boost应该就算一种. 这和
std::thread或boost::thread也没什么区别, 其实c++11的thread就是从boost抄过来的
. 我不觉得这有什么问题, 就像你开发C++用boost没什么问题一样.
以前有人问过的, 怎么copy base class constructor without touching subclass.
以前的答案是template, 新的答案就是inheriting constructor.
语言的发展简化程序员的工作, 我觉得就是这个思路.
最近
起C
出这
有好
有良
别的
【在 n******t 的大作中提到】 : 我觉得这种invention是没边的。。什么功能都想弄出来,最后就是杂和乱。当然我最近 : 很长一段时间可能做系统开发比较多,看法不一定全面。 : variadic template貌似是从C99里面抄过来的? 而且其实C99里面加的新功能其实比起C : ++来说保守太多了,而且都是放到标准里面有不少需求的特性,结果其实际上大部分稍 : 微考虑一点移植性的程序都不太用C99的新功能。 : 至于thread,跨平台的idea固然是没有问题的,但是就这个case来说,在C++里面弄出这 : 么一个内建的功能,比起调用pthread库来说,有什么好处?我的感觉除了麻烦,没有好 : 处。移植性?pthread在所有UNIX和Windows上都有实现,而等到C11在所有平台上都有良 : 好支持恐怕更慢。C++的thread有pthread不能完成的事情么,就我所知没有,反过来呢 : ?一定是有的。加入这么个东西,首先不支持C11的编译器就出问题了,如果还没有别的
| g*****g 发帖数: 34805 | 27 Java这方面做得还是很好的,一个是JDK基本上由Sun开发,没有
互相不兼容的问题。另一个是向后兼容很好。
从语言的角度,其实只有两次大升级。
1-1.1,1.4-1.5
c+
【在 t****t 的大作中提到】 : 新语言标准刚出现肯定会有移植性的问题, 不管你加什么都一样, 因为编译器实现新标 : 准必定有先有后. 如果从这个角度来看问题, 那就真的什么都不要加了, 永远不变最好 : 了. perl 5.8出来很长时间后我还能看到check 5.003的程序. : 这个滞后性是永远没法避免的. jdk1.2 - 1.5中间搞了多少麻烦? 我不用java, 但是我 : 也听说过. 语言总要发展的, 如果没有标准化的话, 那就没人控制朝哪个方向发展. 标 : 准化正是为了避免以后更多的麻烦. : variadic template和C99没关系, 你记错了. 你想说的是variadic macro吧, 那个在c+ : +11里确实有了. tuple还是一个很有用的类, 有了variadic template才方便支持的. : thread在unix和windows上还是有很大不同吧. 我windows不熟, 但是我记得win32的调 : 用应该和pthread并不兼容. 当然肯定有pthread wrapper, boost应该就算一种. 这和
| t****t 发帖数: 6806 | 28 我记得好象当时jvm版本有很多问题吧. 1-1.1不论, 那时候语言应该说还不算成熟. 1.
4时用的人已经很多了. 这就跟VCRT和libstdc++一样, 都没法避免. 但是总会过去的.
【在 g*****g 的大作中提到】 : Java这方面做得还是很好的,一个是JDK基本上由Sun开发,没有 : 互相不兼容的问题。另一个是向后兼容很好。 : 从语言的角度,其实只有两次大升级。 : 1-1.1,1.4-1.5 : : c+
| y**b 发帖数: 10166 | | n******t 发帖数: 4406 | 30 如果就打算推这个, C++肯定就挂了。
这么个四不像,怎么玩啊?
【在 y**b 的大作中提到】 : http://blog.csdn.net/doctorsc/article/details/6777849 : http://sd.csdn.net/a/20111114/307392.html : “C++11就像一门新的语言。” - Bjarne Stroustrup : 好是好,够折腾的。
| | | t****t 发帖数: 6806 | 31 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不
过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度,
还有auto以及range based for, 比如说原来遍历容器需要写:
for (vector::iterator i=c.begin(); i!=c.end(); ++i) {
/* do something to *i */
}
现在可以写:
for (auto i: c) {
/* do something to i */
}
【在 n******t 的大作中提到】 : 如果就打算推这个, C++肯定就挂了。 : 这么个四不像,怎么玩啊?
| A**u 发帖数: 2458 | 32 有点丧失了清晰性..
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| t****t 发帖数: 6806 | 33 我觉得正好相反, 程序变得更清晰更易读了.
【在 A**u 的大作中提到】 : 有点丧失了清晰性..
| y**b 发帖数: 10166 | 34 boost里面的智能指针,分门别类好多种,头大。
c++11搞了两种,是否能一劳永逸解决问题呢,不能的话,
没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
【在 y**b 的大作中提到】 : http://blog.csdn.net/doctorsc/article/details/6777849 : http://sd.csdn.net/a/20111114/307392.html : “C++11就像一门新的语言。” - Bjarne Stroustrup : 好是好,够折腾的。
| h*c 发帖数: 1859 | 35 C++11好像引入了好多关键字。。。
不喜
不过nullptr还是不错的,以前用NULL, BS用0,0是很不好的一个东西啊
【在 y**b 的大作中提到】 : boost里面的智能指针,分门别类好多种,头大。 : c++11搞了两种,是否能一劳永逸解决问题呢,不能的话, : 没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
| t****t 发帖数: 6806 | 36 你说说哪个新关键字让你觉得头疼了?
【在 h*c 的大作中提到】 : C++11好像引入了好多关键字。。。 : 不喜 : 不过nullptr还是不错的,以前用NULL, BS用0,0是很不好的一个东西啊
| s****a 发帖数: 238 | 37 至少lambda函数就很实用,以前为了实现类似的功能很头疼。
它的线程库不知道怎么样。关键是这些新特性基本是独立的,完全可以慢慢过渡 | w***g 发帖数: 5958 | 38 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高
下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。
2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。
除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
【在 t****t 的大作中提到】 : 你说说哪个新关键字让你觉得头疼了?
| t****t 发帖数: 6806 | 39 constexpr我也确实不是很喜欢, 感觉为优化而优化了, 还不如引入var-size array呢.
nullptr我倒觉得没什么, 从一致性的角度来说, NULL这样的大写习惯上是macro, 不合
适成为关键字.
auto我觉得没问题, 多写写就清楚了:)
【在 w***g 的大作中提到】 : 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高 : 下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。 : 2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。 : 除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
| D*******a 发帖数: 3688 | 40 about auto: you may just keep (ab)using it until the compiler squeals!
hiahia
【在 w***g 的大作中提到】 : 1. nullptr和constexpr这两个关键字定义的一点美感也没有。形式上已经和Ritchie高 : 下立现了。要我说还不如把NULL引入成关键字来的好。这样实际上还是跟C兼容的。 : 2. 什么时候用auto什么时候不适合用或者不能用auto不是很直观。 : 除了上面两点吹毛求疵的问题以外,我觉得C++更容易写了。
| | | n******t 发帖数: 4406 | 41 这个算syntax sugar把,我觉得属于可有可无的东西,variadic template C很多C编译
器里面也有类似的的扩展。不过我觉得一个东西有用,不一定要放到 standard里面,反
而对语言推广不利。
还有我觉得没必要把thread弄成语言的组成部分,用平台上的库就好了。
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| t****t 发帖数: 6806 | 42 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也
可以写出所有的程序对吧
但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前,
tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的
case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也
快, 对性能也没影响.
好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平
台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面,
正是为了语言的推广.
,反
【在 n******t 的大作中提到】 : 这个算syntax sugar把,我觉得属于可有可无的东西,variadic template C很多C编译 : 器里面也有类似的的扩展。不过我觉得一个东西有用,不一定要放到 standard里面,反 : 而对语言推广不利。 : 还有我觉得没必要把thread弄成语言的组成部分,用平台上的库就好了。
| d***q 发帖数: 1119 | 43
auto比较好,能省很多事.
不过用 var 可能还好,还能省掉一个字母。
【在 t****t 的大作中提到】 : 这些新东西其实很好用的...很多"新"东西早几年前就在编译器扩展里出现了, 现在不 : 过是合法化. 比如variadic template, 非常好用, 既不容易出错, 又提高编译速度, : 还有auto以及range based for, 比如说原来遍历容器需要写: : for (vector::iterator i=c.begin(); i!=c.end(); ++i) { : /* do something to *i */ : } : 现在可以写: : for (auto i: c) { : /* do something to i */ : }
| d***q 发帖数: 1119 | 44
我用的最多的只有 shared_ptr
【在 y**b 的大作中提到】 : boost里面的智能指针,分门别类好多种,头大。 : c++11搞了两种,是否能一劳永逸解决问题呢,不能的话, : 没有其他好办法吗: 让追求效率的人能追求效率,不追求效率的人能像java追求简单。
| t****t 发帖数: 6806 | 45 do not introduce new keyword unless necessary. auto was almost useless, it's
good to assign a new meaning.
【在 d***q 的大作中提到】 : : 我用的最多的只有 shared_ptr
| d***q 发帖数: 1119 | 46
面,
如果按照 可有可无的说法,很多语言都没有必要存在了。
语法糖很多时候就是差别的来源。喜不喜欢和个人偏好有很大关系。
【在 t****t 的大作中提到】 : 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也 : 可以写出所有的程序对吧 : 但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前, : tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的 : case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也 : 快, 对性能也没影响. : 好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平 : 台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面, : 正是为了语言的推广. :
| t****t 发帖数: 6806 | 47 if i am correct, shared_ptr is the default behaviour of java except GC is
performed immediately. so it's natural that shared_ptr is used the most.
auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr
will becomes useful. current gcc implementation is not as good as
shared_ptr though, for example if T is incomplete, you may experience
problem with instantiating dtor and move (which includes move ctor and move
assignment).
【在 d***q 的大作中提到】 : : 面, : 如果按照 可有可无的说法,很多语言都没有必要存在了。 : 语法糖很多时候就是差别的来源。喜不喜欢和个人偏好有很大关系。
| X****r 发帖数: 3557 | 48 I don't think Java (precisely, any particular JVM) uses reference
counting for pointers.
move
【在 t****t 的大作中提到】 : if i am correct, shared_ptr is the default behaviour of java except GC is : performed immediately. so it's natural that shared_ptr is used the most. : auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr : will becomes useful. current gcc implementation is not as good as : shared_ptr though, for example if T is incomplete, you may experience : problem with instantiating dtor and move (which includes move ctor and move : assignment).
| g*****g 发帖数: 34805 | 49 Of course not, reference couting cannot reclaim cyclic structure.
Most GC algorithms are tracing collectors.
【在 X****r 的大作中提到】 : I don't think Java (precisely, any particular JVM) uses reference : counting for pointers. : : move
| d***q 发帖数: 1119 | 50
move
当然 偶尔也要用 weak_ptr。
解决一些 例如 Parent { Child* children}
Child {Parent* p} 之类的问题。
cycle reference是 引数法的缺陷。 不过实际上我很少会在需要c++的场合使用这种设
计。
原来std带的那个 auto_ptr是太蠢了点。难怪没人愿意用。
【在 t****t 的大作中提到】 : if i am correct, shared_ptr is the default behaviour of java except GC is : performed immediately. so it's natural that shared_ptr is used the most. : auto_ptr is problematic anyway. with c++1x's moving semantics, unique_ptr : will becomes useful. current gcc implementation is not as good as : shared_ptr though, for example if T is incomplete, you may experience : problem with instantiating dtor and move (which includes move ctor and move : assignment).
| | | t****t 发帖数: 6806 | 51 oh...那我土了.
【在 X****r 的大作中提到】 : I don't think Java (precisely, any particular JVM) uses reference : counting for pointers. : : move
| L***n 发帖数: 6727 | 52 受教了
【在 g*****g 的大作中提到】 : Of course not, reference couting cannot reclaim cyclic structure. : Most GC algorithms are tracing collectors.
| n******t 发帖数: 4406 | 53 我觉得这种invention是没边的。。什么功能都想弄出来,最后就是杂和乱。当然我最近
很长一段时间可能做系统开发比较多,看法不一定全面。
variadic template貌似是从C99里面抄过来的? 而且其实C99里面加的新功能其实比起C
++来说保守太多了,而且都是放到标准里面有不少需求的特性,结果其实际上大部分稍
微考虑一点移植性的程序都不太用C99的新功能。
至于thread,跨平台的idea固然是没有问题的,但是就这个case来说,在C++里面弄出这
么一个内建的功能,比起调用pthread库来说,有什么好处?我的感觉除了麻烦,没有好
处。移植性?pthread在所有UNIX和Windows上都有实现,而等到C11在所有平台上都有良
好支持恐怕更慢。C++的thread有pthread不能完成的事情么,就我所知没有,反过来呢
?一定是有的。加入这么个东西,首先不支持C11的编译器就出问题了,如果还没有别的
好处,程序员为什么要用?
我个人的感觉编程打字不是瓶颈,也就是说,如果一个功能推出只是为了少打几个字,
意义不是很大。当然有些时候,简化了句法,同时也简化了思路。但是对于C++来说,我
觉得it从来么有真正做到像java那样的封装程度,也就是说你可以用auto,但是你脑子里
面如果不知道那东西其实是个iterator的话,你很快就会发现你没法真正写稍微大点的
项目,同样iterator你如果对实现没有比较清楚的了解,你一样很快就会撞到让你非常
困惑的问题。从这个角度来数,perl的精简是真正的精简,而C++的这种我觉得只是少打
一些字而已。
面,
【在 t****t 的大作中提到】 : 你要说可有可无当然也不能说错, 因为就算所有C++的特性都没有, 只有C的部分, 你也 : 可以写出所有的程序对吧 : 但是语言发展的目的不就是为了简化程序员的工作么. variadic template出现以前, : tr1的tr1::tuple, tr1::function之类实现很复杂, 要把一个参数到二十多个参数的 : case都enumerate一遍, 也不安全. gcc4.3以后支持这个了, 就简单得多, 编译速度也 : 快, 对性能也没影响. : 好用的东西当然应该放到标准里才利于语言的推广, 要不然我写个东西还要担心换个平 : 台不能用. 跨平台上的thread库早就有了, boost就是, 但是大家还是要放到标准里面, : 正是为了语言的推广. :
| t****t 发帖数: 6806 | 54 新语言标准刚出现肯定会有移植性的问题, 不管你加什么都一样, 因为编译器实现新标
准必定有先有后. 如果从这个角度来看问题, 那就真的什么都不要加了, 永远不变最好
了. perl 5.8出来很长时间后我还能看到check 5.003的程序.
这个滞后性是永远没法避免的. jdk1.2 - 1.5中间搞了多少麻烦? 我不用java, 但是我
也听说过. 语言总要发展的, 如果没有标准化的话, 那就没人控制朝哪个方向发展. 标
准化正是为了避免以后更多的麻烦.
variadic template和C99没关系, 你记错了. 你想说的是variadic macro吧, 那个在c+
+11里确实有了. tuple还是一个很有用的类, 有了variadic template才方便支持的.
thread在unix和windows上还是有很大不同吧. 我windows不熟, 但是我记得win32的调
用应该和pthread并不兼容. 当然肯定有pthread wrapper, boost应该就算一种. 这和
std::thread或boost::thread也没什么区别, 其实c++11的thread就是从boost抄过来的
. 我不觉得这有什么问题, 就像你开发C++用boost没什么问题一样.
以前有人问过的, 怎么copy base class constructor without touching subclass.
以前的答案是template, 新的答案就是inheriting constructor.
语言的发展简化程序员的工作, 我觉得就是这个思路.
最近
起C
出这
有好
有良
别的
【在 n******t 的大作中提到】 : 我觉得这种invention是没边的。。什么功能都想弄出来,最后就是杂和乱。当然我最近 : 很长一段时间可能做系统开发比较多,看法不一定全面。 : variadic template貌似是从C99里面抄过来的? 而且其实C99里面加的新功能其实比起C : ++来说保守太多了,而且都是放到标准里面有不少需求的特性,结果其实际上大部分稍 : 微考虑一点移植性的程序都不太用C99的新功能。 : 至于thread,跨平台的idea固然是没有问题的,但是就这个case来说,在C++里面弄出这 : 么一个内建的功能,比起调用pthread库来说,有什么好处?我的感觉除了麻烦,没有好 : 处。移植性?pthread在所有UNIX和Windows上都有实现,而等到C11在所有平台上都有良 : 好支持恐怕更慢。C++的thread有pthread不能完成的事情么,就我所知没有,反过来呢 : ?一定是有的。加入这么个东西,首先不支持C11的编译器就出问题了,如果还没有别的
| g*****g 发帖数: 34805 | 55 Java这方面做得还是很好的,一个是JDK基本上由Sun开发,没有
互相不兼容的问题。另一个是向后兼容很好。
从语言的角度,其实只有两次大升级。
1-1.1,1.4-1.5
c+
【在 t****t 的大作中提到】 : 新语言标准刚出现肯定会有移植性的问题, 不管你加什么都一样, 因为编译器实现新标 : 准必定有先有后. 如果从这个角度来看问题, 那就真的什么都不要加了, 永远不变最好 : 了. perl 5.8出来很长时间后我还能看到check 5.003的程序. : 这个滞后性是永远没法避免的. jdk1.2 - 1.5中间搞了多少麻烦? 我不用java, 但是我 : 也听说过. 语言总要发展的, 如果没有标准化的话, 那就没人控制朝哪个方向发展. 标 : 准化正是为了避免以后更多的麻烦. : variadic template和C99没关系, 你记错了. 你想说的是variadic macro吧, 那个在c+ : +11里确实有了. tuple还是一个很有用的类, 有了variadic template才方便支持的. : thread在unix和windows上还是有很大不同吧. 我windows不熟, 但是我记得win32的调 : 用应该和pthread并不兼容. 当然肯定有pthread wrapper, boost应该就算一种. 这和
| t****t 发帖数: 6806 | 56 我记得好象当时jvm版本有很多问题吧. 1-1.1不论, 那时候语言应该说还不算成熟. 1.
4时用的人已经很多了. 这就跟VCRT和libstdc++一样, 都没法避免. 但是总会过去的.
【在 g*****g 的大作中提到】 : Java这方面做得还是很好的,一个是JDK基本上由Sun开发,没有 : 互相不兼容的问题。另一个是向后兼容很好。 : 从语言的角度,其实只有两次大升级。 : 1-1.1,1.4-1.5 : : c+
| n******t 发帖数: 4406 | 57 我认为Java能这么干是程序员本身不用操心内存分配的问题,不过我不觉得C++能这么
搞。
【在 g*****g 的大作中提到】 : Java这方面做得还是很好的,一个是JDK基本上由Sun开发,没有 : 互相不兼容的问题。另一个是向后兼容很好。 : 从语言的角度,其实只有两次大升级。 : 1-1.1,1.4-1.5 : : c+
| d***q 发帖数: 1119 | 58
java依然有许多内存相关的问题,不然gc debug,调优,以至于改jvm的都大有人在,
。
【在 n******t 的大作中提到】 : 我认为Java能这么干是程序员本身不用操心内存分配的问题,不过我不觉得C++能这么 : 搞。
| x****u 发帖数: 44466 | 59 C++程序的问题多几个数量级。
【在 d***q 的大作中提到】 : : java依然有许多内存相关的问题,不然gc debug,调优,以至于改jvm的都大有人在, : 。
| n******t 发帖数: 4406 | 60 我觉得一个语言要让一般的程序员用只有两个原因:
1. 不用不行。
2. 可以偷懒。
Java somehow可以保证第二点。
此外,C++其实流行的关键就在与STL,STL出来之前,基本没什么人用C++. (OK,可以说有
人用,不过基本上是用C的写法).
【在 d***q 的大作中提到】 : : java依然有许多内存相关的问题,不然gc debug,调优,以至于改jvm的都大有人在, : 。
| | | n******t 发帖数: 4406 | 61 C++的关键点在于不仅没有让内存管理变简单而且是变复杂了。
虽然说BS说学C++不见得要先懂C,但是我自己认识的程序员里面,学C++前没有学通C的
,基本上写出来的程序就是一个joke.
【在 x****u 的大作中提到】 : C++程序的问题多几个数量级。
| t****t 发帖数: 6806 | 62 是简单还是复杂取决于你怎么用. 如果你把它当作一个C Superset来用, 那的确是复杂
了, 本来C就是malloc/free配对就好了, C++有malloc/free, new/delete, 中间还有可
能抛出的异常夹在里面. 但是如果你换其它的角度来看, 比如说前两天有人说的, 所有
的资源分配一律都是RAII, 只用new和smart pointer, 禁用pointer, 事情实际上是变
简单了.
所以关键还是在程序员的自律. C++是个自由度很高的语言, 如果滥用肯定是没法收场
的. 但是如果都限制死了, 那还不如就用java好了.
【在 n******t 的大作中提到】 : C++的关键点在于不仅没有让内存管理变简单而且是变复杂了。 : 虽然说BS说学C++不见得要先懂C,但是我自己认识的程序员里面,学C++前没有学通C的 : ,基本上写出来的程序就是一个joke.
| EM 发帖数: 715 | 63 如果对速度要求很高的话,是不是用smart pointer不太好?
我看到的很多trading software还是用c写的说。。。
【在 t****t 的大作中提到】 : 是简单还是复杂取决于你怎么用. 如果你把它当作一个C Superset来用, 那的确是复杂 : 了, 本来C就是malloc/free配对就好了, C++有malloc/free, new/delete, 中间还有可 : 能抛出的异常夹在里面. 但是如果你换其它的角度来看, 比如说前两天有人说的, 所有 : 的资源分配一律都是RAII, 只用new和smart pointer, 禁用pointer, 事情实际上是变 : 简单了. : 所以关键还是在程序员的自律. C++是个自由度很高的语言, 如果滥用肯定是没法收场 : 的. 但是如果都限制死了, 那还不如就用java好了.
| g*****g 发帖数: 34805 | 64 程序员自律是很不靠谱的事情,属于一个老鼠屎坏了一锅汤的范畴。
【在 t****t 的大作中提到】 : 是简单还是复杂取决于你怎么用. 如果你把它当作一个C Superset来用, 那的确是复杂 : 了, 本来C就是malloc/free配对就好了, C++有malloc/free, new/delete, 中间还有可 : 能抛出的异常夹在里面. 但是如果你换其它的角度来看, 比如说前两天有人说的, 所有 : 的资源分配一律都是RAII, 只用new和smart pointer, 禁用pointer, 事情实际上是变 : 简单了. : 所以关键还是在程序员的自律. C++是个自由度很高的语言, 如果滥用肯定是没法收场 : 的. 但是如果都限制死了, 那还不如就用java好了.
| t****t 发帖数: 6806 | 65 首先你不能想着两个都占了. 其次smart pointer也慢不了多少.
【在 EM 的大作中提到】 : 如果对速度要求很高的话,是不是用smart pointer不太好? : 我看到的很多trading software还是用c写的说。。。
| t****t 发帖数: 6806 | 66 也不是一定要自律, 也可以在项目里强行规定, 依靠peer review等手段.
总之就是要有规范, 不能想怎么写就怎么写.
【在 g*****g 的大作中提到】 : 程序员自律是很不靠谱的事情,属于一个老鼠屎坏了一锅汤的范畴。
| EM 发帖数: 715 | 67 恩,说的对,use it when needed
【在 t****t 的大作中提到】 : 首先你不能想着两个都占了. 其次smart pointer也慢不了多少.
| N*****m 发帖数: 42603 | 68 java程序员不自律一样出问题,呵呵
【在 g*****g 的大作中提到】 : 程序员自律是很不靠谱的事情,属于一个老鼠屎坏了一锅汤的范畴。
| n******t 发帖数: 4406 | 69 是可以这么干了,但是实际上怎么说吧,一律RAII,和Java比,真的没有多大优势。一
旦自由度高了,其实都差不多,反正都得把事情想清楚,而这一点是大部分程序员并不
喜欢的事情。
【在 t****t 的大作中提到】 : 是简单还是复杂取决于你怎么用. 如果你把它当作一个C Superset来用, 那的确是复杂 : 了, 本来C就是malloc/free配对就好了, C++有malloc/free, new/delete, 中间还有可 : 能抛出的异常夹在里面. 但是如果你换其它的角度来看, 比如说前两天有人说的, 所有 : 的资源分配一律都是RAII, 只用new和smart pointer, 禁用pointer, 事情实际上是变 : 简单了. : 所以关键还是在程序员的自律. C++是个自由度很高的语言, 如果滥用肯定是没法收场 : 的. 但是如果都限制死了, 那还不如就用java好了.
| g*****g 发帖数: 34805 | 70 出错的时候,一个功能不工作跟整个崩掉差别大了。
【在 N*****m 的大作中提到】 : java程序员不自律一样出问题,呵呵
| | | y**b 发帖数: 10166 | 71 现在那些C++教材都是让程序员直接从C++开始,
万不得已无法避开C的东西的时候才提。
实践中C++程序员离开了C能不能做好呢?
要是不能那可就糟了。
【在 n******t 的大作中提到】 : C++的关键点在于不仅没有让内存管理变简单而且是变复杂了。 : 虽然说BS说学C++不见得要先懂C,但是我自己认识的程序员里面,学C++前没有学通C的 : ,基本上写出来的程序就是一个joke.
| y**b 发帖数: 10166 | 72 自律这个事情挺好的,但是得认识到了才可能执行。
非专业程序员认识RAII,本身就不是一件易事。
【在 t****t 的大作中提到】 : 是简单还是复杂取决于你怎么用. 如果你把它当作一个C Superset来用, 那的确是复杂 : 了, 本来C就是malloc/free配对就好了, C++有malloc/free, new/delete, 中间还有可 : 能抛出的异常夹在里面. 但是如果你换其它的角度来看, 比如说前两天有人说的, 所有 : 的资源分配一律都是RAII, 只用new和smart pointer, 禁用pointer, 事情实际上是变 : 简单了. : 所以关键还是在程序员的自律. C++是个自由度很高的语言, 如果滥用肯定是没法收场 : 的. 但是如果都限制死了, 那还不如就用java好了.
| D*******a 发帖数: 3688 | 73 smart pointer是慢些。有些程序里面会有感觉。
【在 EM 的大作中提到】 : 如果对速度要求很高的话,是不是用smart pointer不太好? : 我看到的很多trading software还是用c写的说。。。
|
|