algolicious

Broadcast radio and television.

Here is one. One of the top results right now on Reddit is a picture of Turnip Rock. http://www.reddit.com/r/pics/comments/bp49v/island_pic/ But Wikipedia doesn't have a page on Turnip Rock. Cpedia has one that isn't completely worthless. http://cpedia.com/search?q=turnip+rock

Nope, they seem to think it reflects their vision: http://www.cuil.com/info/blog/2010/04/08/introducing-cpedia-...

Don't be so sure that they don't have permission. Microsoft has implemented Tetris before:

http://en.wikipedia.org/wiki/Microsoft_Entertainment_Pack

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.

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.

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.

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.