4 ms·

Effective C++ by Scott Meyers has some good tips. Here are my tips for you. First tip: Don't trust any C++ code that anyone else writes. This is related to M

Effective C++ by Scott Meyers has some good tips. Here are my tips for you. First tip: Don't trust any C++ code that anyone else writes. This is related to Meyers' tip that C++ is a "federation" of languages. As you have noticed, there is a lot of bad code. But even good code can have bad consequences. C++ is extremely idiosyncratic and the author will make assumptions that you will follow certain practices (deemed as "the right way to program in C++") which will vary from author to author. You may even start to notice this in the comments. Corollary: Only trust a library if it's very well documented and frequently used. Boost may be worth a look, and lots of people like it, but I can't promise that it works. Second tip: avoid reference counting "smart pointers" whenever possible. This directly contradicts Scott Meyers. Instead, use valgrind to make sure your program doesn't leak memory. If your program is infeasible to write without automatic memory management, switch to a language such as Java or C# which is built atop a robust garbage collector. Third tip: view C++ as a bit like an extremely sharp knife. Easy to get things done, even easier to cut your finger off. Just because an example looks slick and easy does not mean that using it in practice is slick and easy.

JamieEi 17y ago
What is your rationale for tip #2? Don't forget that you also have to guard against other kinds of leaks: handles, database connections, etc. Given the lack of a finally clause in standard C++ try/catch blocks I'm not sure how you can do that successfully w/o smart pointers and their ilk.
- algolicious 17y ago
  Of course C++ has RAII, as you must know. Allocate the object on the stack or, if you must, use a stack-allocated auto_ptr if you want it to last as long as the block, as the destructors for stack-allocated objects form the hidden "finally" clause of every block. Otherwise, it is stored somewhere, and the object that stores it should manage it. If you store an object in many different places with no master location, you are starting to wander into automatic memory management territory. As for my rationale, reference counting is by most accounts an obsolete form of garbage collection. The smaller your object is, the more space you waste. If your references are at all cyclic, you have to introduce weak references, in which case you must understand your memory structure to the point where you should be able to manage your memory without garbage collection. (Languages such as Java contain weak references, but are never needed and only should be used for things that the programmer is willing to lose such as a cache.) Cyclic references will creep up on you when you least expect it.
eplawless 17y ago
I disagree as fervently as possible; always use reference counting smart pointers. It is substantially harder to guarantee exception safety if you don't make use of them. You'll also be able to program more quickly without devoting extra mental cycles to make sure everything is cleaned up properly. Using valgrind IN ADDITION is a good idea, but there is no reason to avoid smart pointer memory management.
- algolicious 17y ago
  The best way to deal with exceptions is to disable them. Arbitrary interruptions of control flow will screw up just about any algorithm. Otherwise, you will have to reason about everything using RAII semantics, which work well much of the time. Smart pointers have the same problem. You may believe that everything is cleaned up properly with your smart pointers, until a cyclic reference happens one day.
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 ago
  You 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.

JamieEi 17y ago

What is your rationale for tip #2? Don't forget that you also have to guard against other kinds of leaks: handles, database connections, etc. Given the lack of a finally clause in standard C++ try/catch blocks I'm not sure how you can do that successfully w/o smart pointers and their ilk.

algolicious 17y ago
Of course C++ has RAII, as you must know. Allocate the object on the stack or, if you must, use a stack-allocated auto_ptr if you want it to last as long as the block, as the destructors for stack-allocated objects form the hidden "finally" clause of every block. Otherwise, it is stored somewhere, and the object that stores it should manage it. If you store an object in many different places with no master location, you are starting to wander into automatic memory management territory. As for my rationale, reference counting is by most accounts an obsolete form of garbage collection. The smaller your object is, the more space you waste. If your references are at all cyclic, you have to introduce weak references, in which case you must understand your memory structure to the point where you should be able to manage your memory without garbage collection. (Languages such as Java contain weak references, but are never needed and only should be used for things that the programmer is willing to lose such as a cache.) Cyclic references will creep up on you when you least expect it.

eplawless 17y ago

I disagree as fervently as possible; always use reference counting smart pointers. It is substantially harder to guarantee exception safety if you don't make use of them. You'll also be able to program more quickly without devoting extra mental cycles to make sure everything is cleaned up properly. Using valgrind IN ADDITION is a good idea, but there is no reason to avoid smart pointer memory management.

algolicious 17y ago
The best way to deal with exceptions is to disable them. Arbitrary interruptions of control flow will screw up just about any algorithm. Otherwise, you will have to reason about everything using RAII semantics, which work well much of the time. Smart pointers have the same problem. You may believe that everything is cleaned up properly with your smart pointers, until a cyclic reference happens one day.

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 ago
You 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.