3 ms·
What is it that you don't like about smart pointers? Surely the small performance consequences of using something boost::shared_ptr are outweighed by the excep
by humbledrone 17y ago
What is it that you don't like about smart pointers? Surely the small performance consequences of using something boost::shared_ptr are outweighed by the exception/leak safety that it provides 99% of the time.
You cannot use valgrind to "make sure your program doesn't leak memory." You can only use valgrind to find SOME memory leaks. Particularly for a long-running process (e.g. a daemon), there could be a memory leak that doesn't show up in valgrind unless you run it for 3 weeks. Or what if the daemon only leaks memory on Thursdays, but you test your program under valgrind on Mondays?
I'm not saying that valgrind isn't useful -- it is. But it is NOT a good idea to rely solely on valgrind to find your memory leaks. A much better idea would be to use other techniques (e.g. smart pointers) to avoid memory leaks in the first place, and then to use valgrind on top of that.
- algolicious 17y agoYou are arguing for a solution which works "99% of the time" and then argue that my solution does not work for programs which only leak on Thursdays. Smart pointers won't fix all your memory leaks either due to cyclic references. Any program that runs for 3 weeks should be built to handle restarts, and have a failover architecture in place.