w***g
发帖数: 5958 | 1 GC: immediate solution，表面上看似解决了问题，实际上只是部分
解决了问题，而且同时创造了不止一个新的问题。
RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
解决)，而且同时也解决了所有其他资源分配的问题。
从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
// C++
{
fstream out("xxx");
out << "foo" << endl;
}
//java
OutputStream out = new FileOutputStream("xxx");
out.write("foo\n");
out.close();
可以看到，C++写法里既没有new，也没有close。一对花括号限死了
fstream中所有相关资源的生存期。
而java里，从C++借鉴来一个完全没有必要的new，却没有对应的delete，
而后面的close又没有对应的open。代码没有一点对称性。现在看来，
用来分配内存的new在C++里出现得反而越来越少了，倒是java，
写不了5行程序就得new。
大部分时候，追求全局最优解会比追求局部最优解开销更大，见效更慢，
需要有很有远见的人下狠心坚持下来。但是稍微放长远一点看，效果就会
非常明显。
这种类似的情况在C++和java两个语言里非常多。比如实现generic，
C++是一种全局最优解，到后来都能发展出函数式语言这种开始完全不在
计划之中的写法。而java的type erasure则是一种局部最优解，解决了
大部分问题，但是没法扩展，语言再要发展，去掉也不是，不去掉也不是。
再比如编译，一开始图方便用stack-based虚拟机(为什么是stack-based，
国内上过编译课写过mini pascal的都知道，连汇编语言都不用学，
就可以写编译器)，然后性能搞不定了才折腾
JIT编译，又过了这么多年，性能还是搞不定，又要折腾AOT编译。
整个语言都是假设虚拟机设计的，这么多库也都是假设虚拟机设计的，
现在要搞编译谈何容易。看看pypy就知道，解决兼容性问题的开销可能是
做编译器开销的100倍都不止。从哪儿找那么多人擦屁股去？
再比如支持多继承，C++的做法虽然繁杂，但是干净，就一个class。
java的interface就是一个部分的解决方法（java没有多继承跟GC做不好
也有关系，一个局部最优解导致另一个局部最优解)。到了scala，
还是得弄出trait来颠覆interface。但trait也不是全局最优解，因为
按继承顺序不同，不同的trait的构造函数是否被调用是不确定的。
C++和java的生命期估计都不下几十年，未来发展的路还很长。
为什么C++往标准里加个GC都翻来覆去好几年决定不了，非不能也，
是不为也，因为你现在加进去，将来再想拿出来就难了。有一句话叫
人无远虑必有近优，用在C++和java上都合适。
我这是纯从技术角度出发思考，实际可能很多事情则是由经济文化等
因素甚至是人的本性决定的。GC比RAII更popular这个结果，早在100
年前亨利福特的攒钱消费理念败给GMVC的借钱消费理念那时就已经定了，
再往前推，其实早在2000年前蔡桓公讳疾忌医那时候就已经定了。 |
x****k
发帖数: 2932 | 2 坐等原教旨java programmer来喷lz |
d****i
发帖数: 4809 | 3 写的不错顶一个，C++里面和C一样如无特殊必要尽量使用stack variable，这样可以保
证stack unwinding自动释放清除资源而不用任何GC，而且速度比使用heap快很多。
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
p***o
发帖数: 1252 | 4 拿啥喷? Java 7里面的try-with-resources吗?
【在 x****k 的大作中提到】
: 坐等原教旨java programmer来喷lz
|
y*******t
发帖数: 69 | |
N******K
发帖数: 10202 | 6 彰显我辈用c+的优越性和先进性
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
d********t
发帖数: 9628 | 7 顶!
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
n******n
发帖数: 12088 | 8 不懂咖啡，不过给的代码确实是C++漂亮
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
g*****g
发帖数: 34805 | 9 RAII is a partial solution at best.
1. It's far from elegant once you allocate from heap and start using smart
pointer. And smart point has the fatal issues of not able to dealing with
circular pointers etc. And let's face it, not everything can be stored in
stack. i.e. It's a mumbo jumbo technique at best.
2. It's not enforced by compiler at all. You can't even count on your
colleague doing it consistently, let alone 3rd party.
At the end of the day, memory leak is still consistently an issue, a big one
for C++, while on Java side is almost non-existent and easy to identify.
Everybody writing code in the right way is daystreaming and you need to wake
up from it. I never count on others to do the right thing, I count on
JVM to do the right thing (proper GC), and tools to show me the right
information to debug when the wrong
thing is done.
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
s******u
发帖数: 501 | 10 写的非常的赞
很多把smart pointer误解为C++的GC，但真正的精髓在于stack variable和unwinding
到处写满shared_ptr的人其实都没有得到C++
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
|
|
b*******s
发帖数: 5216 | 11 就是轻量级解决和重量级解决的区别。轻量级的好维护，容易扩展。重量级的对应用层
程序猿要求低，不是科班也能混混，出活虽然污糟但快。
不管轻重，基本功不够的走不远 |
d*******r
发帖数: 3299 | 12 C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存,
比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?)
内存回收逻辑放入 shared Object destructor 吧.
如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收? |
w**z
发帖数: 8232 | 13 Memory leak is one problem, the other one is dangling references. For most
of the applications, GC is good enough.
Of course, for latency sensitive applications, Java might not be a good fit.
I used to spend days, hours to figure out what the heck is the segment fault
coming from.
one
wake
【在 g*****g 的大作中提到】
: RAII is a partial solution at best.
: 1. It's far from elegant once you allocate from heap and start using smart
: pointer. And smart point has the fatal issues of not able to dealing with
: circular pointers etc. And let's face it, not everything can be stored in
: stack. i.e. It's a mumbo jumbo technique at best.
: 2. It's not enforced by compiler at all. You can't even count on your
: colleague doing it consistently, let alone 3rd party.
: At the end of the day, memory leak is still consistently an issue, a big one
: for C++, while on Java side is almost non-existent and easy to identify.
: Everybody writing code in the right way is daystreaming and you need to wake
|
g*********9
发帖数: 1285 | 14 jvm还有不用gc的，不过要花银子，c++已经末日黄花了。
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
w***g
发帖数: 5958 | 15 你给个具体的需求，我帮你想怎么样能干净地解决。你说的这个是解决方案，并不是需
求。你的解决方案可能不是最优的，所以会出现程序难写的情况。
shared object in the heap经常用。谁分配的谁负责释放。
这样基本上不需要shared_ptr。甚至不需要new，而是用&获取局部变量的指针
传出去。一般一个设计方案做到内存分配简化了，往往还会有别的好处。
实现和维护都能变容易。
【在 d*******r 的大作中提到】
: C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存,
: 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?)
: 内存回收逻辑放入 shared Object destructor 吧.
: 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
|
y*j
发帖数: 3139 | 16 Use Shared_ptr
【在 d*******r 的大作中提到】
: C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存,
: 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?)
: 内存回收逻辑放入 shared Object destructor 吧.
: 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
|
w**z
发帖数: 8232 | 17 you mean zing?
http://www.azulsystems.com/products/zing/whatisit
They claimed it to be pauseless. I went to a few of their talks. But never
tried.
Do you use it?
【在 g*********9 的大作中提到】
: jvm还有不用gc的，不过要花银子，c++已经末日黄花了。
|
y*j
发帖数: 3139 | 18 Use smart pointer correctly, you will never have segment fault.
If your code is old and cannot use smart pointer, just follow big three
rules.
fit.
fault
【在 w**z 的大作中提到】
: Memory leak is one problem, the other one is dangling references. For most
: of the applications, GC is good enough.
: Of course, for latency sensitive applications, Java might not be a good fit.
:
: I used to spend days, hours to figure out what the heck is the segment fault
: coming from.
:
: one
: wake
|
s******u
发帖数: 501 | 19 share使用同一块内存没有问题，但是注意使用权不等于所有权，一块内存一般只属于
单一的一个owner，然后由这个owner来决定什么时候把这块内存收回。ownership可以
transfer，但是co-ownership的话通常意味着设计可能有点问题
做设计的时候内存（变量）的ownership和lifetime都是非常重要的概念。
【在 d*******r 的大作中提到】
: C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存,
: 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?)
: 内存回收逻辑放入 shared Object destructor 吧.
: 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
|
w***g
发帖数: 5958 | 20 就是这样。我发现很多人写程序没有设计这一步，上手就写，思维混乱。
这种人就会特别依赖gc或者smart_ptr。
【在 s******u 的大作中提到】
: share使用同一块内存没有问题，但是注意使用权不等于所有权，一块内存一般只属于
: 单一的一个owner，然后由这个owner来决定什么时候把这块内存收回。ownership可以
: transfer，但是co-ownership的话通常意味着设计可能有点问题
: 做设计的时候内存（变量）的ownership和lifetime都是非常重要的概念。
|
|
|
y*j
发帖数: 3139 | 21 Use weak_ptr to break circular reference。
一个设计合理的程序应该不会出现Circular reference。
one
wake
【在 g*****g 的大作中提到】
: RAII is a partial solution at best.
: 1. It's far from elegant once you allocate from heap and start using smart
: pointer. And smart point has the fatal issues of not able to dealing with
: circular pointers etc. And let's face it, not everything can be stored in
: stack. i.e. It's a mumbo jumbo technique at best.
: 2. It's not enforced by compiler at all. You can't even count on your
: colleague doing it consistently, let alone 3rd party.
: At the end of the day, memory leak is still consistently an issue, a big one
: for C++, while on Java side is almost non-existent and easy to identify.
: Everybody writing code in the right way is daystreaming and you need to wake
|
y*j
发帖数: 3139 | 22 还是用smart pointer 简单省事，毕竟机器比人可靠，当然要少用，只有heavy object
用，light object 放stack 上就可以了。
【在 w***g 的大作中提到】
: 就是这样。我发现很多人写程序没有设计这一步，上手就写，思维混乱。
: 这种人就会特别依赖gc或者smart_ptr。
|
x****k
发帖数: 2932 | 23 再把多线程,加解锁,granularity,lockless,atomic之类弄上,够某些bad programmer喝
一壶的.呵呵
【在 s******u 的大作中提到】
: share使用同一块内存没有问题，但是注意使用权不等于所有权，一块内存一般只属于
: 单一的一个owner，然后由这个owner来决定什么时候把这块内存收回。ownership可以
: transfer，但是co-ownership的话通常意味着设计可能有点问题
: 做设计的时候内存（变量）的ownership和lifetime都是非常重要的概念。
|
y*j
发帖数: 3139 | 24 以前看巜儒林外史》有这么一段：
八股文若做的好，随你做什么东西，要诗就诗，要赋就赋，都是一鞭一条痕，一掴一掌
血。
c++ 和这八股文有异曲同工之妙
【在 x****k 的大作中提到】
: 再把多线程,加解锁,granularity,lockless,atomic之类弄上,够某些bad programmer喝
: 一壶的.呵呵
|
k***j
发帖数: 411 | 25 一点屁大点的编译器特性，让你说的跟诈尸了似的。。。
楼主肯定没读过c++ standard doc
RAII是编程范式
GC是内存管理机制
完全两种不同概念，有什么好混在一起谈的
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
x****k
发帖数: 2932 | 26 c/c++是基础的东西,掌握好了在弄那些jvm base language不难.反过来只知道上层语言
规则,不理解内在运行机制,如果出了问题就不好弄.当然了用上层语言的目的就是少出
问题.
【在 y*j 的大作中提到】
: 以前看巜儒林外史》有这么一段：
: 八股文若做的好，随你做什么东西，要诗就诗，要赋就赋，都是一鞭一条痕，一掴一掌
: 血。
: c++ 和这八股文有异曲同工之妙
|
g*****g
发帖数: 34805 | 27 It's an ad hoc practice at best and it's not easy to detect when a mistake
is made, that's far inferior to a GC solution.
If you think you can write GC better than dedicated GC deveoper, think again
. It's OK to use C++ when latency is critical, but if you believe RAII is a
better solution in general, you must be smoking.
【在 y*j 的大作中提到】
: Use weak_ptr to break circular reference。
: 一个设计合理的程序应该不会出现Circular reference。
:
: one
: wake
|
d*******r
发帖数: 3299 | 28 我以前就是写 C++ 的, 我觉得 smart pointer 挺难用的, 11版的没用过.
自己手动管理内存的话, 自己一人的程序还好, 人多了的大项目也挺麻烦的.
以前每次改个 bug, 费时最久的步骤, 就是把里外3层的内存管理代码看一遍, 因为每
个人管理内存的 style 还不太一样, 得按照原作者的思路加东西. |
y*j
发帖数: 3139 | 29 Java GC 对付Circular reference 确实很高明，我承认我达不到他们的水平。但我总
感觉这是个人造问题，如果设计差到出现循环引用，那他也可以写出死循环的程序，
java一样完蛋。再说了，如果是非内存资源，java就不如c++好管理了。
again
a
【在 g*****g 的大作中提到】
: It's an ad hoc practice at best and it's not easy to detect when a mistake
: is made, that's far inferior to a GC solution.
: If you think you can write GC better than dedicated GC deveoper, think again
: . It's OK to use C++ when latency is critical, but if you believe RAII is a
: better solution in general, you must be smoking.
|
b*******s
发帖数: 5216 | 30 and it is not difficult to find circular ref by using static analysis tools
【在 y*j 的大作中提到】
: Use weak_ptr to break circular reference。
: 一个设计合理的程序应该不会出现Circular reference。
:
: one
: wake
|
|
|
b*******s
发帖数: 5216 | 31 you don't get him
object
【在 y*j 的大作中提到】
: 还是用smart pointer 简单省事，毕竟机器比人可靠，当然要少用，只有heavy object
: 用，light object 放stack 上就可以了。
|
y*j
发帖数: 3139 | 32 那是因为很多人写C++，实际上是写C，如果严格遵循big three rules，不用smart
pointer 也可以。
【在 d*******r 的大作中提到】
: 我以前就是写 C++ 的, 我觉得 smart pointer 挺难用的, 11版的没用过.
: 自己手动管理内存的话, 自己一人的程序还好, 人多了的大项目也挺麻烦的.
: 以前每次改个 bug, 费时最久的步骤, 就是把里外3层的内存管理代码看一遍, 因为每
: 个人管理内存的 style 还不太一样, 得按照原作者的思路加东西.
|
g*****g
发帖数: 34805 | 33 Circular ref is not an issue for GC at all. If there's no other ref into the
loop, the entire loop can be reclaimed.
Java has checked exception, it's harder to forget reclaiming resource than C
++ in general. If that's not enough, when a bug is hit, a nice exception
stack makes debugging much easier.
【在 y*j 的大作中提到】
: Java GC 对付Circular reference 确实很高明，我承认我达不到他们的水平。但我总
: 感觉这是个人造问题，如果设计差到出现循环引用，那他也可以写出死循环的程序，
: java一样完蛋。再说了，如果是非内存资源，java就不如c++好管理了。
:
: again
: a
|
y*j
发帖数: 3139 | 34 java exception check helps。很多人写c++忘了这一点。
如果用RAII，非内存资源会自动释放的
the
C
【在 g*****g 的大作中提到】
: Circular ref is not an issue for GC at all. If there's no other ref into the
: loop, the entire loop can be reclaimed.
: Java has checked exception, it's harder to forget reclaiming resource than C
: ++ in general. If that's not enough, when a bug is hit, a nice exception
: stack makes debugging much easier.
|
w***g
发帖数: 5958 | 35 RAII和GC是解决资源管理问题的两种不同的方法。一种通过编程范式解决，另一种通过
runtime/库解决。GC也可以用来解决别的资源，比如文件，锁等的自动释放问题。
混在一起谈很合适啊。
【在 k***j 的大作中提到】
: 一点屁大点的编译器特性，让你说的跟诈尸了似的。。。
: 楼主肯定没读过c++ standard doc
: RAII是编程范式
: GC是内存管理机制
: 完全两种不同概念，有什么好混在一起谈的
|
m**********s
发帖数: 518 | 36 恰恰相反，GC是更高瞻远瞩的技术路线，RAII是局部优化对付对付。
GC假定机器比人可靠，假定算法最终能自动释放资源。
RAII强迫码农采用特定的范式去编程，它假定人对范式的理解是一致的，并且人是不犯
错误的。
回到现实世界，GC并不最优因为算法不够牛；RAII也一样，再牛的码工也不可能不写出
bug，而且码工越资深，埋的bug越隐蔽越致命。
GC: immediate solution，表面上看似解决了问题，实际上只是部分解决了问题，而且
同时创造了不止一个新的问题。RAII: 本质的解决方案，不止解决了内存分配一类....
....
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
q*c
发帖数: 9453 | 37 总是有人相信共产主义，总是有人认为（很多人的情况下）人能靠的住。
3000 万人都没把这种人死绝啊。。。
【在 d*******r 的大作中提到】
: 我以前就是写 C++ 的, 我觉得 smart pointer 挺难用的, 11版的没用过.
: 自己手动管理内存的话, 自己一人的程序还好, 人多了的大项目也挺麻烦的.
: 以前每次改个 bug, 费时最久的步骤, 就是把里外3层的内存管理代码看一遍, 因为每
: 个人管理内存的 style 还不太一样, 得按照原作者的思路加东西.
|
q*c
发帖数: 9453 | 38 如果人人都大公无私，共产主义不就实现了嘛。 要不要去最接近的北朝鲜体验一下下？
【在 y*j 的大作中提到】
: 那是因为很多人写C++，实际上是写C，如果严格遵循big three rules，不用smart
: pointer 也可以。
|
s*****t
发帖数: 89 | 39 很久以前操作系统课上一个用c写的内存分配一类的程序就是segfault,死活都找不出问
题,TA也帮忙找了还是不行，最后因为在gdb里面能跑出结果还是给了分。
当然这和我写代码的水平不高有关，渐渐就不怎么写软件了。最近才开始学rust，突然
明白以前搞不清楚的问题所在了，痛苦折腾中领悟到了你们说的ownership和lifetime
，不过还没有完全转过来，都是靠编译器报错来找的。
大牛如果有机会指导指导。 |
g*****g
发帖数: 34805 | 40 没给人擦过屁股的总是想着自己多么牛逼，给人擦过屁股的总是不惮怀疑别人比见识过
的还傻逼，实力其实两下就看出来了。
【在 q*c 的大作中提到】
: 总是有人相信共产主义，总是有人认为（很多人的情况下）人能靠的住。
: 3000 万人都没把这种人死绝啊。。。
|
|
|
y*j
发帖数: 3139 | 41 如果抬杠的话，写GC的大牛们更资深，所以埋的Bug更隐蔽更致命？
..
【在 m**********s 的大作中提到】
: 恰恰相反，GC是更高瞻远瞩的技术路线，RAII是局部优化对付对付。
: GC假定机器比人可靠，假定算法最终能自动释放资源。
: RAII强迫码农采用特定的范式去编程，它假定人对范式的理解是一致的，并且人是不犯
: 错误的。
: 回到现实世界，GC并不最优因为算法不够牛；RAII也一样，再牛的码工也不可能不写出
: bug，而且码工越资深，埋的bug越隐蔽越致命。
:
: GC: immediate solution，表面上看似解决了问题，实际上只是部分解决了问题，而且
: 同时创造了不止一个新的问题。RAII: 本质的解决方案，不止解决了内存分配一类....
: ....
|
y*j
发帖数: 3139 | 42 我经常给别人擦屁股，看过各种烂Code，在这过程中其实学到很多东西，水平提高很多。
【在 g*****g 的大作中提到】
: 没给人擦过屁股的总是想着自己多么牛逼，给人擦过屁股的总是不惮怀疑别人比见识过
: 的还傻逼，实力其实两下就看出来了。
|
y*j
发帖数: 3139 | 43 其实说的没错，每次看到这种用C++写C程序的时候，还不如完全用C得了，不要像中国
朝鲜一样，挂社会主义的羊头，卖资本主义，封建主义的狗肉。
下？
【在 q*c 的大作中提到】
: 如果人人都大公无私，共产主义不就实现了嘛。 要不要去最接近的北朝鲜体验一下下？
|
b*******s
发帖数: 5216 | 44 号称自己是写c++的，十个有八个是这种，还有一个是写mfc的
【在 y*j 的大作中提到】
: 其实说的没错，每次看到这种用C++写C程序的时候，还不如完全用C得了，不要像中国
: 朝鲜一样，挂社会主义的羊头，卖资本主义，封建主义的狗肉。
:
: 下？
|
J*****s
发帖数: 110 | 45 Bingo.
smart pointer 的陷阱太多，虽说每种smart pointer用在不同的场合使用。新手能很
快的入门掌握，但是要熟练用到大项目对程序员要求高。
我曾经就被lifetime的问题搞个半死。还有smartpointer乱用导致内存暴增。
【在 s******u 的大作中提到】
: share使用同一块内存没有问题，但是注意使用权不等于所有权，一块内存一般只属于
: 单一的一个owner，然后由这个owner来决定什么时候把这块内存收回。ownership可以
: transfer，但是co-ownership的话通常意味着设计可能有点问题
: 做设计的时候内存（变量）的ownership和lifetime都是非常重要的概念。
|
d*******r
发帖数: 3299 | 46 关键是 C++ 因为 C 的历史负担, 开发工具落后 (gcc/g++, make, 长时间没好的 IDE)
,
没有建立起好的生态圈, 很多时候, 连些像样的 lib 都没有, 结果就是一堆人自己写
自己的,
工程上和生态圈上都不成功.
【在 y*j 的大作中提到】
: 其实说的没错，每次看到这种用C++写C程序的时候，还不如完全用C得了，不要像中国
: 朝鲜一样，挂社会主义的羊头，卖资本主义，封建主义的狗肉。
:
: 下？
|
y*j
发帖数: 3139 | 47 c++ 最大的问题确实是缺少一个好的生态环境。boost 算是部分解决方案。但我感觉
Boost作者的水平比Java库作者的水平要差一些。
还有缺少reflection.
IDE)
【在 d*******r 的大作中提到】
: 关键是 C++ 因为 C 的历史负担, 开发工具落后 (gcc/g++, make, 长时间没好的 IDE)
: ,
: 没有建立起好的生态圈, 很多时候, 连些像样的 lib 都没有, 结果就是一堆人自己写
: 自己的,
: 工程上和生态圈上都不成功.
|
n******n
发帖数: 12088 | 48 看烂代码肯定比起好代码学的少，有时候还负作用。
多。
【在 y*j 的大作中提到】
: 我经常给别人擦屁股，看过各种烂Code，在这过程中其实学到很多东西，水平提高很多。
|
n******n
发帖数: 12088 | 49 缺feature这个见仁见智。
【在 y*j 的大作中提到】
: c++ 最大的问题确实是缺少一个好的生态环境。boost 算是部分解决方案。但我感觉
: Boost作者的水平比Java库作者的水平要差一些。
: 还有缺少reflection.
:
: IDE)
|
d****i
发帖数: 4809 | 50 你要理解C++的主要focus是performance，所以任何drag performance的东西都不会引
入，比如反射是要以牺牲performance为代价的，这对于C++是不可接受的。
【在 y*j 的大作中提到】
: c++ 最大的问题确实是缺少一个好的生态环境。boost 算是部分解决方案。但我感觉
: Boost作者的水平比Java库作者的水平要差一些。
: 还有缺少reflection.
:
: IDE)
|
|
|
d****i
发帖数: 4809 | 51 你的认识是错误的。恰恰相反，GCC/GDB，Makefile加上vi/vim是最好的写代码的工具
，当然对于初学者来说你可以用一长串的IDE的list来点fancy的GUI，但是没有在UNIX/
Linux下用过GCC/Makefile/vim的程序员不算是真正的程序员。
IDE)
【在 d*******r 的大作中提到】
: 关键是 C++ 因为 C 的历史负担, 开发工具落后 (gcc/g++, make, 长时间没好的 IDE)
: ,
: 没有建立起好的生态圈, 很多时候, 连些像样的 lib 都没有, 结果就是一堆人自己写
: 自己的,
: 工程上和生态圈上都不成功.
|
y*j
发帖数: 3139 | 52 那是。刚开始学的时候看烂代码，那会误入歧途。有一定基础再去修补烂代码，你会收
获不少，你会深刻理解为什么需要那些好东西。
【在 n******n 的大作中提到】
: 看烂代码肯定比起好代码学的少，有时候还负作用。
:
: 多。
|
y*j
发帖数: 3139 | 53 这我理解，但是一个稍微成熟的反射库都没有，不过也许我孤陋寡闻
【在 d****i 的大作中提到】
: 你要理解C++的主要focus是performance，所以任何drag performance的东西都不会引
: 入，比如反射是要以牺牲performance为代价的，这对于C++是不可接受的。
|
h**********c
发帖数: 4120 | 54 is it said new/delete in benchmarking cause more ticks than streamlined GC? |
h**********c
发帖数: 4120 | 55 Just like vb, Java was written in oo style c. I think today c/c++ usually is
the same compiler. |
w**z
发帖数: 8232 | 56 ide 不仅是fancy UI. 你对现代ide的认识不够。把两个能熟练运用ide 和 vim 的人放
在一起， 我不相信用vim的效率会高。
UNIX/
【在 d****i 的大作中提到】
: 你的认识是错误的。恰恰相反，GCC/GDB，Makefile加上vi/vim是最好的写代码的工具
: ，当然对于初学者来说你可以用一长串的IDE的list来点fancy的GUI，但是没有在UNIX/
: Linux下用过GCC/Makefile/vim的程序员不算是真正的程序员。
:
: IDE)
|
d*******r
发帖数: 3299 | 57 这些工具真的很原始...
用过, 会用这些工具, 并且认识到他们的原始性,
只有在不得不用的时候才用, 才是与时俱进 :)
UNIX/
【在 d****i 的大作中提到】
: 你的认识是错误的。恰恰相反，GCC/GDB，Makefile加上vi/vim是最好的写代码的工具
: ，当然对于初学者来说你可以用一长串的IDE的list来点fancy的GUI，但是没有在UNIX/
: Linux下用过GCC/Makefile/vim的程序员不算是真正的程序员。
:
: IDE)
|
d****i
发帖数: 4809 | 58 我也不是vim的高手，不过我写Java的话从来不用vim都是用Eclipse，但是写C,C++,PHP
,JavaScript,Python等其他语言的时候还是经常会用，尤其如果你要上server写的话，
不用vim的话就没法了。我们公司一个同事才是厉害，写code从来不用IDE，全部vi（不
是vim）,用的是一台HP-UX的工作站，写起来嗖嗖的飞快, 让我想起当年我在国内工作
的时候在Solaris下直接用vi写C程序的时代。
【在 w**z 的大作中提到】
: ide 不仅是fancy UI. 你对现代ide的认识不够。把两个能熟练运用ide 和 vim 的人放
: 在一起， 我不相信用vim的效率会高。
:
: UNIX/
|
s******u
发帖数: 501 | 59 所以在你看起来所有字符界面的都是原始，GUI就是先进的？呵呵
【在 d*******r 的大作中提到】
: 这些工具真的很原始...
: 用过, 会用这些工具, 并且认识到他们的原始性,
: 只有在不得不用的时候才用, 才是与时俱进 :)
:
: UNIX/
|
g*****g
发帖数: 34805 | 60 你这个说明的是Linux上写C/C++没有趁手的工具，当年写MFC有人不用VS的吗？
PHP
【在 d****i 的大作中提到】
: 我也不是vim的高手，不过我写Java的话从来不用vim都是用Eclipse，但是写C,C++,PHP
: ,JavaScript,Python等其他语言的时候还是经常会用，尤其如果你要上server写的话，
: 不用vim的话就没法了。我们公司一个同事才是厉害，写code从来不用IDE，全部vi（不
: 是vim）,用的是一台HP-UX的工作站，写起来嗖嗖的飞快, 让我想起当年我在国内工作
: 的时候在Solaris下直接用vi写C程序的时代。
|
|
|
d*******r
发帖数: 3299 | 61 你这是乱扣帽子了, 我哪里说过 GUI vs 字符 的问题?
Make, vim/emacs VS IDE 这种讨论本版太多了, 你可以考考古
【在 s******u 的大作中提到】
: 所以在你看起来所有字符界面的都是原始，GUI就是先进的？呵呵
|
n******n
发帖数: 12088 | 62 前两个可以，也有改进空间。后两个老掉牙的东西，趁早废了吧。
UNIX/
【在 d****i 的大作中提到】
: 你的认识是错误的。恰恰相反，GCC/GDB，Makefile加上vi/vim是最好的写代码的工具
: ，当然对于初学者来说你可以用一长串的IDE的list来点fancy的GUI，但是没有在UNIX/
: Linux下用过GCC/Makefile/vim的程序员不算是真正的程序员。
:
: IDE)
|
n******n
发帖数: 12088 | 63 找个不需要修补烂代码的工作吧。烂代码越修越烂。
【在 y*j 的大作中提到】
: 那是。刚开始学的时候看烂代码，那会误入歧途。有一定基础再去修补烂代码，你会收
: 获不少，你会深刻理解为什么需要那些好东西。
|
n******n
发帖数: 12088 | 64 我有个朋友骑车嗖嗖的快。可他还是买了汽车。
PHP
【在 d****i 的大作中提到】
: 我也不是vim的高手，不过我写Java的话从来不用vim都是用Eclipse，但是写C,C++,PHP
: ,JavaScript,Python等其他语言的时候还是经常会用，尤其如果你要上server写的话，
: 不用vim的话就没法了。我们公司一个同事才是厉害，写code从来不用IDE，全部vi（不
: 是vim）,用的是一台HP-UX的工作站，写起来嗖嗖的飞快, 让我想起当年我在国内工作
: 的时候在Solaris下直接用vi写C程序的时代。
|
k**********g
发帖数: 989 | 65 刚复习了一次Java的 Closeable, AutoCloseable 文档，蓦然回首，发现葵版感觉的很
穿越。。。
早就說了 RAII 的名字改得不好，應該是 Scope-based resource management 才對。 |
z****e
发帖数: 54598 | 66 让我想起马车和汽车的赛跑
落后于时代的人总会认为一些老旧的东西是无法被淘汰的
【在 w**z 的大作中提到】
: ide 不仅是fancy UI. 你对现代ide的认识不够。把两个能熟练运用ide 和 vim 的人放
: 在一起， 我不相信用vim的效率会高。
:
: UNIX/
|
w******w
发帖数: 126 | 67 你的意思是在多线程情况下，如何保证share的 object的 功能正确吧？
你这个问题非常好。特别是在多线程情况下，什么时候释放一个share 的object，如何
释放一个share的object，解决办法是用著名的 smart pointers 可以解决这个问题。
当然在运用的时候还是有很多的小技巧的。
BTW，我想这样的细节著名的大 Java 程序员们是不会care的！
：）
【在 d*******r 的大作中提到】
: C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存,
: 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?)
: 内存回收逻辑放入 shared Object destructor 吧.
: 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
|
z****e
发帖数: 54598 | 68 几个遗老遗少而已
已经沦为笑话了
【在 k**********g 的大作中提到】
: 刚复习了一次Java的 Closeable, AutoCloseable 文档，蓦然回首，发现葵版感觉的很
: 穿越。。。
: 早就說了 RAII 的名字改得不好，應該是 Scope-based resource management 才對。
|
w******w
发帖数: 126 | 69 1 可以用 weak pointer 这种智能pointer 解决你的concern
2 不讲以前的legacy code， 现代的C++ 的开发人员，已经比较难写出来 memory
leaking 的code了。 当然了 如果是刚写C++ 时间不长的人，那另当别论！
one
wake
【在 g*****g 的大作中提到】
: RAII is a partial solution at best.
: 1. It's far from elegant once you allocate from heap and start using smart
: pointer. And smart point has the fatal issues of not able to dealing with
: circular pointers etc. And let's face it, not everything can be stored in
: stack. i.e. It's a mumbo jumbo technique at best.
: 2. It's not enforced by compiler at all. You can't even count on your
: colleague doing it consistently, let alone 3rd party.
: At the end of the day, memory leak is still consistently an issue, a big one
: for C++, while on Java side is almost non-existent and easy to identify.
: Everybody writing code in the right way is daystreaming and you need to wake
|
z****e
发帖数: 54598 | 70 去掉goto就是局部最优解
如果有全局最优解的话
傻子都会做出来，选择意味着放弃
c对于汇编来说，到处也都是局部最优解
如果你纠缠于全局最优解的话
人类是没法进步的
因为数学本身就不自洽，你的最优解从一开始就崩塌了
物理学，硬件这些根本无从谈起，数学理论根本就无法成立
【在 w***g 的大作中提到】
: GC: immediate solution，表面上看似解决了问题，实际上只是部分
: 解决了问题，而且同时创造了不止一个新的问题。
: RAII: 本质的解决方案，不止解决了内存分配一类问题（这个也是部分
: 解决)，而且同时也解决了所有其他资源分配的问题。
: 从技术的角度上来说，我觉得这两者高下立判。看似都没有显式的
: 资源回收，前者是纵容用户，后者则是培养一种思维方式，写出来
: 的东西都是防患与未然的。就是代码写出来，也是C++的更简洁：
: // C++
: {
: fstream out("xxx");
|
|
|
z****e
发帖数: 54598 | 71 你从一开始就不应该上server去写代码
只有不得不做的时候才这么做
绝大多数时候你应该在ide中完成代码的书写测试甚至部署工作
你在server上写代码，难道你们连java code都放server上去？
PHP
【在 d****i 的大作中提到】
: 我也不是vim的高手，不过我写Java的话从来不用vim都是用Eclipse，但是写C,C++,PHP
: ,JavaScript,Python等其他语言的时候还是经常会用，尤其如果你要上server写的话，
: 不用vim的话就没法了。我们公司一个同事才是厉害，写code从来不用IDE，全部vi（不
: 是vim）,用的是一台HP-UX的工作站，写起来嗖嗖的飞快, 让我想起当年我在国内工作
: 的时候在Solaris下直接用vi写C程序的时代。
|
y*j
发帖数: 3139 | 72 咦，你不正好说明Java也开始用RAII管理资源吗？
【在 k**********g 的大作中提到】
: 刚复习了一次Java的 Closeable, AutoCloseable 文档，蓦然回首，发现葵版感觉的很
: 穿越。。。
: 早就說了 RAII 的名字改得不好，應該是 Scope-based resource management 才對。
|
w***g
发帖数: 5958 | 73 你真是少见多怪。我所有的code都是在server上的。
【在 z****e 的大作中提到】
: 你从一开始就不应该上server去写代码
: 只有不得不做的时候才这么做
: 绝大多数时候你应该在ide中完成代码的书写测试甚至部署工作
: 你在server上写代码，难道你们连java code都放server上去？
:
: PHP
|
z****e
发帖数: 54598 | 74 prod. server?
你好意思
这种做法要是被我以前的公司看到
这个理由是可以fire掉的，代码是需要保密的
不是放到server给维护人员随便偷的
生产server和放code的git server必需分离
不过你们没有跨平台，脚本是解释执行，所以这两个都决定了无法像java一样
把编译后的byte code和source code分开存放
因为需要放到server上去compile，和debug
【在 w***g 的大作中提到】
: 你真是少见多怪。我所有的code都是在server上的。
|
z****e
发帖数: 54598 | 75 source code里面有一堆app key之类的这key那key
尤其是social website经常给各种key，比如twitter
你把key交出去，就等于把商业机密交了出去，你也真敢做啊
佩服
【在 w***g 的大作中提到】
: 你真是少见多怪。我所有的code都是在server上的。
|
g*****g
发帖数: 34805 | 76 只要正确得写代码，内存泄漏是不会出现的。你没发现你跟没说一样？
【在 w******w 的大作中提到】
: 1 可以用 weak pointer 这种智能pointer 解决你的concern
: 2 不讲以前的legacy code， 现代的C++ 的开发人员，已经比较难写出来 memory
: leaking 的code了。 当然了 如果是刚写C++ 时间不长的人，那另当别论！
:
: one
: wake
|
z****e
发帖数: 54598 | 77 顺便，你放在db里面的密码是不是明文保存？
加盐了吗？
【在 w***g 的大作中提到】
: 你真是少见多怪。我所有的code都是在server上的。
|
w***g
发帖数: 5958 | 78 production server也有，development server也有。我自己的台式机也是
linux，配的raid，基本上就是我的development server。就是偶尔要用
笔记本写程序做实验，也是ssh到台式机上。偶尔出差，也可以ssh到台式
机上。
对于跟数据打交道的人，其实没有别的办法。最近python和R开始出了一些
可以在网页上处理数据的东西，但远还没有达到不用ssh的地步。
我跟你做的东西差得太远，不指望你能理解。
【在 z****e 的大作中提到】
: prod. server?
: 你好意思
: 这种做法要是被我以前的公司看到
: 这个理由是可以fire掉的，代码是需要保密的
: 不是放到server给维护人员随便偷的
: 生产server和放code的git server必需分离
: 不过你们没有跨平台，脚本是解释执行，所以这两个都决定了无法像java一样
: 把编译后的byte code和source code分开存放
: 因为需要放到server上去compile，和debug
|
z****e
发帖数: 54598 | 79 c++不能做到跨平台，当然不能像我们这样控制了
这就是c++的傻逼之处，跨平台这种东西早就该解决掉
而不是丢给程序员去搞，最后一身屎
r和python都有跨平台，但是一旦涉及到c的pkg，那就难说了
呵呵，所谓跨平台噩梦说的就是如此
java当初广告里面一个跨平台就打动了无数人，gc什么还是次要的
【在 w***g 的大作中提到】
: production server也有，development server也有。我自己的台式机也是
: linux，配的raid，基本上就是我的development server。就是偶尔要用
: 笔记本写程序做实验，也是ssh到台式机上。偶尔出差，也可以ssh到台式
: 机上。
: 对于跟数据打交道的人，其实没有别的办法。最近python和R开始出了一些
: 可以在网页上处理数据的东西，但远还没有达到不用ssh的地步。
: 我跟你做的东西差得太远，不指望你能理解。
|
s******u
发帖数: 501 | 80 那你为什么说gcc/gdb原始呢？
vim和IDE没什么好吵的，一个是文本编辑软件，一个是IDE，完全两个概念，根本没有
放在一起比较的必要
【在 d*******r 的大作中提到】
: 你这是乱扣帽子了, 我哪里说过 GUI vs 字符 的问题?
: Make, vim/emacs VS IDE 这种讨论本版太多了, 你可以考考古
|
