Abednego

I don't think this is enough for a lot of common cases. Let's say you want to write a 'sort()' function. It takes a 'vector' and a comparator function. Unless that comparator function is declared 'const', you can't be sure that it won't destroy your 'vector'.

Another example. Let's say your 'foo()' function calls 'bar.toString()'. How can the compiler tell whether this call should be allowed when 'bar' is 'const'? You would need to know whether 'toString()' modifies 'bar' or not, but you don't have a way to tell. You might be able to figure this out if you look inside the code of 'toString()', but what if 'toString()' is virtual? You can't look at the code then.

I think you might like Python.

I would argue that automatic inference of 'const' is a very bad idea because it defeats the whole purpose of having 'const' in the first place -- to catch bugs at compile time. If somebody modifies 'find()' in a way that makes it non-const, then your code will continue compiling without errors. However, if somebody relies on the fact that 'count()' is const, then that person would be royally screwed, and it will take weeks to find the bug.

Google Code Jam allows BOOST and all other freely available languages and libraries.

"Real libraries"? Hey!

Thanks. I'm glad you find them useful.

Thanks for the summary. This is my code. I've since switched to using "Bst" instead of "BST" for class names. I've also stopped putting spaces inside parentheses and angle brackets. Although I still think that code looks better with the spaces, I realize that most people don't format it that way, and I'm fine going with the popular convention.

This really sucks for angle brackets though. Compare

vector<pair<int, string> > blah;

to

vector< pair< int, string > > blah;