D***n
发帖数: 6804 | 1 基本上我认为这些特性都是C++的糟粕：
1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
被塞入各种特化。
我的建议：STL一类成熟的可以用，但是能不用就不用。
2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
吧，这个东西引起的麻烦远远超过其便利性。
至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
称用于链接，这个替换协议不仅不是标准的一部份，而且还巨复杂。2）只能重载基本
类型。基本上就是一个残废功能。
我的方法：与其让系统自动起名字，不如我自己给他起，比如 init_IntInt, init_Int
, int
4）const
当我读到 Thinking in C++ ，作者开始介绍const的时候，我就开始讨厌C++了，因为
const位置不同有一大堆不同的解释，特别是和指针，指针的指针，对象配合在一起的
时候。
5）拷贝构造函数
我就不明白为啥C++总是和简单的赋值语句过不去。还老喜欢在函数调用前后悄悄塞自
动代码。 |
m*********a
发帖数: 3299 | 2 我在做极大大数，和极小的数的时候，需要分成a(coeffient),b(exponent)
Class Number{
double coeffient;
long long exponent;
}
的时候，还是要overloading operator + - * / 和= +=, -=, *=, /=
const Number Number::operator-(const Number &n) const；
这个const 还是个大坑 |
m*********a
发帖数: 3299 | 3 template为啥必须和header file 在一起？ |
N******K
发帖数: 10202 | 4 坐等c++大牛们把你劈成渣滓
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
w*n
发帖数: 1259 | 5 听赞成的，这样写的代码可能多一些，但是看起来比较方便 |
p***o
发帖数: 1252 | 6 那还不如用java
【在 w*n 的大作中提到】
: 听赞成的，这样写的代码可能多一些，但是看起来比较方便
|
w***g
发帖数: 5958 | 7 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
应该加const的地方都加上const。写多线程程序这一点很重要。
const的语义有一个非常简单的规则：const永远只修饰它immediately左边的那个东西。
比如
int const * p;
int * const q;
p = ...没问题，但是*p = ...不行
q = ...不行，但是*q = ...没问题。
加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
函数调用所有进去的都以const &传入(除了POD)，所有出来的都以指针传入。
写C++设计和封装非常重要。很多恶心东西是必不可少的，但是只要不让它跨越接口，
一般后患就不会太多。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
a*********a
发帖数: 3656 | 8 函数名和类名编译的时候总是要mangle的。如果你对over loaded function name
decoration不满意，那等你看到编译后的class name，岂不是要吐血？如果你的函数不
需要从别的语言调用，那name mangling完全无关。如果要从别的语言调用，那name
mangling是很多问题中极其trivial的一个。
“只能重载基本类型。”是啥意思？ 一个ostream::operator<< 就不知道被多少自定
义的高级类重载了。
关于“函数调用前后悄悄塞自动代码。” c++传值给了你3种选择，by value，by
reference，by pointer。后两种都不调用copy constructor。如果细分的话，by
reference to const和by pointer to const在语义上和非 const的有显著区别。有的
语言，只支持by value或by reference。前者无法改变传递过来的参数，后者如果你要
在函数内部对参数操作但是不改变call site的变量值，那还是得自己做deep copy。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
a*********a
发帖数: 3656 | 9 yes, when in doubt, read/write from the right. "const A * const" :)
所有
西。
【在 w***g 的大作中提到】
: 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
: 应该加const的地方都加上const。写多线程程序这一点很重要。
: const的语义有一个非常简单的规则：const永远只修饰它immediately左边的那个东西。
: 比如
: int const * p;
: int * const q;
: p = ...没问题，但是*p = ...不行
: q = ...不行，但是*q = ...没问题。
: 加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
: 函数调用所有进去的都以const &传入(除了POD)，所有出来的都以指针传入。
|
m*********a
发帖数: 3299 | 10 这句没有看懂
----------------------
传入的话，用const &,需要修改传入的话，用&,传出不是用return的copy constructor?
比如MyClass myClass;//declare on local stack
//do some thing with myClass
return myClass;
//myClass is copied and local myClass is out of scope and destroyed. |
|
|
n****l
发帖数: 3375 | 11 c++ 最主要的是std库设计的煞笔
本来能够写的更方便的调用的函数，结果搞的莫名其妙
比如std string 的替换字符串
一般人直观的去想，应该有一个replace(string, string)和replace_all(string,
string)吧
或者多个replace，一种是replace(start_pos, end_pos, string)，一种是replace(
string, string)，这种在c++里面都能实现。
结果呢？ std标准库里面只实现了replace(start_pos, end_pos, string)，每次替换
字符串的时候不仅一句话完不了，还得好几行， 啰嗦至极。 网上使用std string
replace都是自己再写个函数，要是没有反思精神的人还以为这仅仅是c++的特性，实际
这是c++的bug，丢人的地方。 |
p***o
发帖数: 1252 | 12 iostream和string都属于史前时代的遗留问题。
【在 n****l 的大作中提到】
: c++ 最主要的是std库设计的煞笔
: 本来能够写的更方便的调用的函数，结果搞的莫名其妙
: 比如std string 的替换字符串
: 一般人直观的去想，应该有一个replace(string, string)和replace_all(string,
: string)吧
: 或者多个replace，一种是replace(start_pos, end_pos, string)，一种是replace(
: string, string)，这种在c++里面都能实现。
: 结果呢？ std标准库里面只实现了replace(start_pos, end_pos, string)，每次替换
: 字符串的时候不仅一句话完不了，还得好几行， 啰嗦至极。 网上使用std string
: replace都是自己再写个函数，要是没有反思精神的人还以为这仅仅是c++的特性，实际
|
B********e
发帖数: 1062 | 13 For C++ if you don't know the feature well, just don't use it. There is
nothing wrong with it
Do not overload operators
Do not overload functions
Do not use templates
You are still able to finish your project nice and clean without these. That
's the beauty of c++.
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
D***n
发帖数: 6804 | 14 感谢讨论。
Mangle这个的主要问题是没有标准化，如果你有很多模块需要链接，经常出很多莫名奇
妙的问题，说你xxx方法没实现，以前遇到很多次。
只能重载基本类型的意思是，很多项目的参数类型是一个宏，类似UINT这样的，这个宏
在不同平台，不同头文件下可能被typedef不同的类型也有可能定义成同一种基础类型
，经常导致出错。你想调用A，结果最后发现跑到B那里去了，或者链接时给你报错找不
到实现。
关于自动代码：我真的很不喜欢这个设计，除了把人绕糊涂没任何好处，我认为C++传
值就应该一个选择：像C一样只能传基本类型，引用改成固定用法：const int * xxx
或者干脆像ObjC那样直接起个名字叫ref, id之类。
【在 a*********a 的大作中提到】
: 函数名和类名编译的时候总是要mangle的。如果你对over loaded function name
: decoration不满意，那等你看到编译后的class name，岂不是要吐血？如果你的函数不
: 需要从别的语言调用，那name mangling完全无关。如果要从别的语言调用，那name
: mangling是很多问题中极其trivial的一个。
: “只能重载基本类型。”是啥意思？ 一个ostream::operator<< 就不知道被多少自定
: 义的高级类重载了。
: 关于“函数调用前后悄悄塞自动代码。” c++传值给了你3种选择，by value，by
: reference，by pointer。后两种都不调用copy constructor。如果细分的话，by
: reference to const和by pointer to const在语义上和非 const的有显著区别。有的
: 语言，只支持by value或by reference。前者无法改变传递过来的参数，后者如果你要
|
D***n
发帖数: 6804 | 15 我对此有看法，代码里面满篇的const，真的是很难看。
不过如果编译器知道函数参数指向的对象在整个函数运行期间不会改变，有个很大的优
化好处，具体记不住了。
所有
西。
【在 w***g 的大作中提到】
: 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
: 应该加const的地方都加上const。写多线程程序这一点很重要。
: const的语义有一个非常简单的规则：const永远只修饰它immediately左边的那个东西。
: 比如
: int const * p;
: int * const q;
: p = ...没问题，但是*p = ...不行
: q = ...不行，但是*q = ...没问题。
: 加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
: 函数调用所有进去的都以const &传入(除了POD)，所有出来的都以指针传入。
|
t**r
发帖数: 3428 | 16 code review的时候，
关于const可以review 很多 非常容易打架。
【在 D***n 的大作中提到】
: 我对此有看法，代码里面满篇的const，真的是很难看。
: 不过如果编译器知道函数参数指向的对象在整个函数运行期间不会改变，有个很大的优
: 化好处，具体记不住了。
:
: 所有
: 西。
|
w***g
发帖数: 5958 | 17 STL是有复杂度和性能要求的。像replace这种操作不出现STL中是我觉得至少是说的过
去的。
【在 n****l 的大作中提到】
: c++ 最主要的是std库设计的煞笔
: 本来能够写的更方便的调用的函数，结果搞的莫名其妙
: 比如std string 的替换字符串
: 一般人直观的去想，应该有一个replace(string, string)和replace_all(string,
: string)吧
: 或者多个replace，一种是replace(start_pos, end_pos, string)，一种是replace(
: string, string)，这种在c++里面都能实现。
: 结果呢？ std标准库里面只实现了replace(start_pos, end_pos, string)，每次替换
: 字符串的时候不仅一句话完不了，还得好几行， 啰嗦至极。 网上使用std string
: replace都是自己再写个函数，要是没有反思精神的人还以为这仅仅是c++的特性，实际
|
D***n
发帖数: 6804 | 18 想起来是什么了。可以优化执行顺序，比如：
c = add(a, b) ;
d = mul(a, b)；
如果编译器知道add一定不会修改a和b ，(a和b对add函数来说是个常量），那么这两条
语句可以并行执行。
【在 D***n 的大作中提到】
: 我对此有看法，代码里面满篇的const，真的是很难看。
: 不过如果编译器知道函数参数指向的对象在整个函数运行期间不会改变，有个很大的优
: 化好处，具体记不住了。
:
: 所有
: 西。
|
w***g
发帖数: 5958 | 19 编译优化其实好处不大。主要是为了简化设计和逻辑。
对一个数据结构，读写最好在时间上和代码上都分开：
- 创建完结构就不再写了，以后一直就是读。这样完全避免了同步问题。
- 最好只有一段代码负责写，别的都是只读。
写一个数据结构的时间和代码越多，程序就越不容易理解，越容易出错，
出了错越越难debug。
【在 D***n 的大作中提到】
: 想起来是什么了。可以优化执行顺序，比如：
: c = add(a, b) ;
: d = mul(a, b)；
: 如果编译器知道add一定不会修改a和b ，(a和b对add函数来说是个常量），那么这两条
: 语句可以并行执行。
|
r***s
发帖数: 737 | 20 应该是小心使用，不要滥用。 这和能不用就不用还是差不少的。
template的本意是在避免code clone的同时让你能有尽量多的compiler safety check.
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
|
|
s******c
发帖数: 1920 | 21 关于C++ ， google C++ code style guide其实是一本圣经 。这是Google几千万行C++
代码下来最精华的经验总结。
里面确实总结且ban了很多C++的糟粕。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
w******w
发帖数: 126 | 22 我的理解是 C++ 的 template 是把 数据结构 跟 算法的剥离。
template 只是注重对于数据的处理而忽视具体数据类型的本身。
template 我的个人理解也是在编译的时候实现多态，而不是在run time 当中实现多态
。貌似有点点这个的味道。
check.
【在 r***s 的大作中提到】
: 应该是小心使用，不要滥用。 这和能不用就不用还是差不少的。
: template的本意是在避免code clone的同时让你能有尽量多的compiler safety check.
|
a*********a
发帖数: 3656 | 23 also some times const vars don't have to be allocated at all. they can be
placed inline by the compiler. the compiler can even do some computation at
compile time.
static const int a = 5;
static const int b = 2;
...
int c = a+b;
I suspect the compiler can just init c to 7, no run time operations. if this
is the only place a and b are used, no address would be allocated for a and
b on stack at all.
【在 D***n 的大作中提到】
: 想起来是什么了。可以优化执行顺序，比如：
: c = add(a, b) ;
: d = mul(a, b)；
: 如果编译器知道add一定不会修改a和b ，(a和b对add函数来说是个常量），那么这两条
: 语句可以并行执行。
|
o**o
发帖数: 3964 | 24 运算符重载的确是以辞害意，over engineering。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
c*******9
发帖数: 9032 | 25 运算符重载是好东西，不然有些表达式长的没法看。
【在 o**o 的大作中提到】
: 运算符重载的确是以辞害意，over engineering。
|
h*******u
发帖数: 15326 | 26 nod
【在 c*******9 的大作中提到】
: 运算符重载是好东西，不然有些表达式长的没法看。
|
h******k
发帖数: 388 | 27 凡是Java不用的特性都是糟粕！要不发明Java的大牛为什么不实现那个特性。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
h******k
发帖数: 388 | 28 太复杂，可读性不好容易出错。Java的final简单多了
所有
西。
【在 w***g 的大作中提到】
: 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
: 应该加const的地方都加上const。写多线程程序这一点很重要。
: const的语义有一个非常简单的规则：const永远只修饰它immediately左边的那个东西。
: 比如
: int const * p;
: int * const q;
: p = ...没问题，但是*p = ...不行
: q = ...不行，但是*q = ...没问题。
: 加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
: 函数调用所有进去的都以const &传入(除了POD)，所有出来的都以指针传入。
|
h*****0
发帖数: 4889 | 29
所有
西。
这个跟copy ellision以及c++11的move语义放在一起相当的不和谐啊。
control
种：
，你
现实
数名
【在 w***g 的大作中提到】
: 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
: 应该加const的地方都加上const。写多线程程序这一点很重要。
: const的语义有一个非常简单的规则：const永远只修饰它immediately左边的那个东西。
: 比如
: int const * p;
: int * const q;
: p = ...没问题，但是*p = ...不行
: q = ...不行，但是*q = ...没问题。
: 加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
: 函数调用所有进去的都以const &传入(除了POD)，所有出来的都以指针传入。
|
g*****g
发帖数: 34805 | 30 所有语言都是东西加进去容易，拿出来太难了。你觉得是糟粕，当并不能阻止其他人这
么写。远有C++，近有Scala. |
|
|
m***i
发帖数: 2480 | 31 楼主牛啊。好几条都是coding style里提到的
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
N******K
发帖数: 10202 | 32 智商堪忧 请自觉转java
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕：
: 1）模板：模板的本意是把type和control flow分开，多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种：
: 被塞入各种特化。
: 我的建议：STL一类成熟的可以用，但是能不用就不用。
: 2）基本操作符重载：当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候，你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗？面对现实
: 吧，这个东西引起的麻烦远远超过其便利性。
: 至少至少，重载的操作符应该和正常符号分开，比如 = 改成 |= 一类。
: 3）重载：重载是个好主意，问题在：1）库里面这些重载的函数会被替换成别的函数名
|
d****i
发帖数: 4809 | 33 Jave的final和C++的const完全不是一回事情，C++的const能够保证传入的参数不被改
变，而Java的final则完全不能保证。
【在 h******k 的大作中提到】
: 太复杂，可读性不好容易出错。Java的final简单多了
:
: 所有
: 西。
|
b*******s
发帖数: 5216 | 34 你根本没懂为什么要这样设计
【在 n****l 的大作中提到】
: c++ 最主要的是std库设计的煞笔
: 本来能够写的更方便的调用的函数，结果搞的莫名其妙
: 比如std string 的替换字符串
: 一般人直观的去想，应该有一个replace(string, string)和replace_all(string,
: string)吧
: 或者多个replace，一种是replace(start_pos, end_pos, string)，一种是replace(
: string, string)，这种在c++里面都能实现。
: 结果呢？ std标准库里面只实现了replace(start_pos, end_pos, string)，每次替换
: 字符串的时候不仅一句话完不了，还得好几行， 啰嗦至极。 网上使用std string
: replace都是自己再写个函数，要是没有反思精神的人还以为这仅仅是c++的特性，实际
|
b*******s
发帖数: 5216 | 35 golang去掉了，operator overloading我觉得是不错，但是要减少使用
除非必须
【在 c*******9 的大作中提到】
: 运算符重载是好东西，不然有些表达式长的没法看。
|
b*******s
发帖数: 5216 | 36 所以c++代码起码可以有四五种风格，比如很多人喜欢的带类的c，大多数这里的"c++程
序员"都是这个风格的，大概98年左右的风格。都15年前的c++风格了，每天工作再长，
比如超过10小时，也就是不停的修补自己的错误，严格来说，不算现代c++程序员，早
点改行最好
各种风格不建议混用，尤其是糊里糊涂的时候，比如上面抱怨函数替换的那位。培养自
己的风格最重要
【在 g*****g 的大作中提到】
: 所有语言都是东西加进去容易，拿出来太难了。你觉得是糟粕，当并不能阻止其他人这
: 么写。远有C++，近有Scala.
|
b*******s
发帖数: 5216 | 37 相对于滥用模板，我觉得滥用OO要严重得多。我觉得所有产生超过2层继承的c++代码，
都应该打回去重写
【在 N******K 的大作中提到】
: 智商堪忧 请自觉转java
|
t*****n
发帖数: 4908 | 38 我没看错吧？！？￥%……&&×
【在 b*******s 的大作中提到】
: 相对于滥用模板，我觉得滥用OO要严重得多。我觉得所有产生超过2层继承的c++代码，
: 都应该打回去重写
|
w****i
发帖数: 964 | 39 template is one of the most powerful parts of C++
operator overloading is kinda syntax sugar
function overloading const are hell |
n****l
发帖数: 3375 | 40 都标准库了还扯什么个人风格
既然这个需要个人风格，需要自己积累一个个性化的标准库
那把这个蹩脚的玩意儿移出标准库就好了，或者干脆取消标准库
所有的私有库自由竞争
这就跟用emacs的，有人说emacs不好用是因为你没配置好
说这话的人可以自己贴出自己的全套插件配置啊
但是最后去社区问，你这个插件配置好了么
再去查几乎全网上几乎没几个人搞好的，emacs社区也在不断萎缩
把蹩脚说成个人掌握不好是纯粹推卸责任
事实就是这些开源软件因为无法盈利所以作者都三心二意懒得修bug
这也是那句不是bug是feature的由来
我自己当然已经有累计的库，包括log thread socket singleton database config
crashhandler 等等，但是我还是要喷c++标准库设计的煞笔
一门语言是众人使用的，众人设计，是众人之事
一小撮什么标准委员会来制定一坨狗屎让大家吃属于独裁
以后的程序设计语言，很有可能编译器之间p2p联网
是否修改语法，怎么修改语法由所有人共同决定
标准库也是像github那样看fork star数来决定，而不是靠权威靠垄断
想象下当你打开ide的时候，自动联网，像google的搜索自动提示那样自动完成（只不
过内容来源从网站变成了全民的代码库），编译出错误以后自动显示出stackoverflow
上面的最佳答案，这样不是很美好么
让所有的蹩脚繁琐都去死吧
【在 b*******s 的大作中提到】
: 所以c++代码起码可以有四五种风格，比如很多人喜欢的带类的c，大多数这里的"c++程
: 序员"都是这个风格的，大概98年左右的风格。都15年前的c++风格了，每天工作再长，
: 比如超过10小时，也就是不停的修补自己的错误，严格来说，不算现代c++程序员，早
: 点改行最好
: 各种风格不建议混用，尤其是糊里糊涂的时候，比如上面抱怨函数替换的那位。培养自
: 己的风格最重要
|
|
|
G***l
发帖数: 355 | 41 你确定？google那个是写给java程序员的c++ guide。适合c++初学者或者一知半解的人
。真正懂c++，要发挥c++的优势去写一个严肃的东西的team是根本不会用这种初学者
guide的。如果一个项目不适合c++，那就别用。如果要用，就要真正的懂c++。
++
【在 s******c 的大作中提到】
: 关于C++ ， google C++ code style guide其实是一本圣经 。这是Google几千万行C++
: 代码下来最精华的经验总结。
: 里面确实总结且ban了很多C++的糟粕。
|
N******K
发帖数: 10202 | 42 继承太多 成员变量记不住了 急需IDE 整一个变量表
【在 b*******s 的大作中提到】
: 相对于滥用模板，我觉得滥用OO要严重得多。我觉得所有产生超过2层继承的c++代码，
: 都应该打回去重写
|
l******g
发帖数: 366 | 43 我觉得异常最不该用。你永远不知道调用你的代码是否handle住了 |
t*****n
发帖数: 4908 | 44 10层的继承也没问题。不用ide基本就是自虐。上个cdt看百万级代码都游刃有余。
【在 N******K 的大作中提到】
: 继承太多 成员变量记不住了 急需IDE 整一个变量表
|
