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.
C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存, 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?) 内存回收逻辑放入 shared Object destructor 吧. 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
w*z
34 楼
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
你给个具体的需求,我帮你想怎么样能干净地解决。你说的这个是解决方案,并不是需 求。你的解决方案可能不是最优的,所以会出现程序难写的情况。 shared object in the heap经常用。谁分配的谁负责释放。 这样基本上不需要shared_ptr。甚至不需要new,而是用&获取局部变量的指针 传出去。一般一个设计方案做到内存分配简化了,往往还会有别的好处。 实现和维护都能变容易。
【在 d*******r 的大作中提到】 : C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存, : 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?) : 内存回收逻辑放入 shared Object destructor 吧. : 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
y*j
37 楼
Use Shared_ptr
【在 d*******r 的大作中提到】 : C++ 高手们展开说说, 如果有很多地方都 share 了同一块内存, : 比如一个 shared Object in heap (难道说这个应用场景 C++ 高手不使用?) : 内存回收逻辑放入 shared Object destructor 吧. : 如何总是能简洁并保险地回收内存? 还是能用 RAII 风格来回收?
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
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
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
【在 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
51 楼
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
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
【在 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.
【在 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