A*e
2 楼
J2反签, 符合中信递签的条件, 所以到中信去递签. 但是我的DS2019表现在因为J1延了
两年而换了一张新的, 而中信死活不同意提交这张新的2019的原件, 只给复印件. 而我
记得我以往面签的时候VO是要在2019表上签字的, 如果这张新的表不签字, 我难道带着
只有HR和我自己签字的表过美国海关吗? 有没有人经历过同样的事.
两年而换了一张新的, 而中信死活不同意提交这张新的2019的原件, 只给复印件. 而我
记得我以往面签的时候VO是要在2019表上签字的, 如果这张新的表不签字, 我难道带着
只有HR和我自己签字的表过美国海关吗? 有没有人经历过同样的事.
D*n
3 楼
基本上我认为这些特性都是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++总是和简单的赋值语句过不去。还老喜欢在函数调用前后悄悄塞自
动代码。
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++总是和简单的赋值语句过不去。还老喜欢在函数调用前后悄悄塞自
动代码。
n*8
4 楼
怎么没人回啊?自己顶一下!
m*a
6 楼
我在做极大大数,和极小的数的时候,需要分成a(coeffient),b(exponent)
Class Number{
double coeffient;
long long exponent;
}
的时候,还是要overloading operator + - * / 和= +=, -=, *=, /=
const Number Number::operator-(const Number &n) const;
这个const 还是个大坑
Class Number{
double coeffient;
long long exponent;
}
的时候,还是要overloading operator + - * / 和= +=, -=, *=, /=
const Number Number::operator-(const Number &n) const;
这个const 还是个大坑
m*a
7 楼
template为啥必须和header file 在一起?
N*K
8 楼
坐等c++大牛们把你劈成渣滓
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
w*n
9 楼
听赞成的,这样写的代码可能多一些,但是看起来比较方便
w*g
11 楼
别的都不值得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)库里面这些重载的函数会被替换成别的函数名
应该加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
12 楼
函数名和类名编译的时候总是要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)库里面这些重载的函数会被替换成别的函数名
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
13 楼
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),所有出来的都以指针传入。
所有
西。
【在 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
14 楼
这句没有看懂
----------------------
传入的话,用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.
----------------------
传入的话,用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
15 楼
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,丢人的地方。
本来能够写的更方便的调用的函数,结果搞的莫名其妙
比如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
16 楼
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++的特性,实际
【在 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
17 楼
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)库里面这些重载的函数会被替换成别的函数名
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
18 楼
感谢讨论。
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。前者无法改变传递过来的参数,后者如果你要
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
19 楼
我对此有看法,代码里面满篇的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),所有出来的都以指针传入。
不过如果编译器知道函数参数指向的对象在整个函数运行期间不会改变,有个很大的优
化好处,具体记不住了。
所有
西。
【在 w***g 的大作中提到】
: 别的都不值得argue了。const是一个很重要的特性。一个减少错误最好的办法就是在所有
: 应该加const的地方都加上const。写多线程程序这一点很重要。
: const的语义有一个非常简单的规则:const永远只修饰它immediately左边的那个东西。
: 比如
: int const * p;
: int * const q;
: p = ...没问题,但是*p = ...不行
: q = ...不行,但是*q = ...没问题。
: 加多少层都不会搞混。像const int a这种写法应该彻底杜绝。
: 函数调用所有进去的都以const &传入(除了POD),所有出来的都以指针传入。
w*g
21 楼
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++的特性,实际
去的。
【在 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++的特性,实际
r*s
24 楼
应该是小心使用,不要滥用。 这和能不用就不用还是差不少的。
template的本意是在避免code clone的同时让你能有尽量多的compiler safety check.
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
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
25 楼
关于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)库里面这些重载的函数会被替换成别的函数名
代码下来最精华的经验总结。
里面确实总结且ban了很多C++的糟粕。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
a*a
27 楼
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函数来说是个常量),那么这两条
: 语句可以并行执行。
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
28 楼
运算符重载的确是以辞害意,over engineering。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
h*k
31 楼
凡是Java不用的特性都是糟粕!要不发明Java的大牛为什么不实现那个特性。
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
h*k
32 楼
太复杂,可读性不好容易出错。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),所有出来的都以指针传入。
所有
西。
【在 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
33 楼
所有
西。
这个跟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
34 楼
所有语言都是东西加进去容易,拿出来太难了。你觉得是糟粕,当并不能阻止其他人这
么写。远有C++,近有Scala.
么写。远有C++,近有Scala.
m*i
35 楼
楼主牛啊。好几条都是coding style里提到的
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
N*K
36 楼
智商堪忧 请自觉转java
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
【在 D***n 的大作中提到】
: 基本上我认为这些特性都是C++的糟粕:
: 1)模板:模板的本意是把type和control flow分开,多个type可以共享一个control
: flow。但是它引发的问题远比带来的方便程度要多。最后大多数模板都搞成一个杂种:
: 被塞入各种特化。
: 我的建议:STL一类成熟的可以用,但是能不用就不用。
: 2)基本操作符重载:当一个正常人看到A=B居然引发了另外一个线程SIGABT的时候,你
: 会想到这么一个赋值语句居然触发了某个析构函数把内存给清空了的事情吗?面对现实
: 吧,这个东西引起的麻烦远远超过其便利性。
: 至少至少,重载的操作符应该和正常符号分开,比如 = 改成 |= 一类。
: 3)重载:重载是个好主意,问题在:1)库里面这些重载的函数会被替换成别的函数名
b*s
38 楼
你根本没懂为什么要这样设计
【在 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++的特性,实际
【在 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++的特性,实际
w*i
43 楼
template is one of the most powerful parts of C++
operator overloading is kinda syntax sugar
function overloading const are hell
operator overloading is kinda syntax sugar
function overloading const are hell
n*l
44 楼
都标准库了还扯什么个人风格
既然这个需要个人风格,需要自己积累一个个性化的标准库
那把这个蹩脚的玩意儿移出标准库就好了,或者干脆取消标准库
所有的私有库自由竞争
这就跟用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++程序员,早
: 点改行最好
: 各种风格不建议混用,尤其是糊里糊涂的时候,比如上面抱怨函数替换的那位。培养自
: 己的风格最重要
既然这个需要个人风格,需要自己积累一个个性化的标准库
那把这个蹩脚的玩意儿移出标准库就好了,或者干脆取消标准库
所有的私有库自由竞争
这就跟用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++程序员,早
: 点改行最好
: 各种风格不建议混用,尤其是糊里糊涂的时候,比如上面抱怨函数替换的那位。培养自
: 己的风格最重要
l*g
47 楼
我觉得异常最不该用。你永远不知道调用你的代码是否handle住了
相关阅读
学java的找工作好苦逼呀一个关于unordered_map/hashmap的问题rest in go 就是 martini了?硅工和马工是一家。码工搬砖,硅工和沙子node.js大家一般用什么framework?go 怎么 disable这个call server api cross domain的问题大家用什么code search/review工具?gorm 是不是只支持mysql postgre, sqlite3? #golang #go #restful为什么大牛说hbase是strong consistency的?Java 9 Date is setbest Android & iPhone cross-platform dev framework?coroutine or thread后端码农的职业该怎么发展G用的什么技术?王垠:我的个人防火墙(MITBBS惨被黑) (转载)问一个python内存管理的问题Why Couchbase chose RxJava for the new Java SDK试用了两个新的论坛软件Node.js question on identifying 2 different web browser tab/pages