ilari wrote:C++ should not be thought of as better C - it's a different language and it should be used differently. Fruit is a good example of how to use C++ without really using C++, and Stockfish is a great example of how C++ should be used.
I completely disagree with this.
C++ is a horrible language. If you have to write a high-level program and you can't just use something like Python, then I guess C++ can get the job done. But for low-level code, most of its language features are a double-edged sword, making it easy to bleed away the performance advantage of C without even noticing.
If you want to write "nice C++" then go ahead, but writing "proper C++ code" with lots of RAII, virtual functions, default constructors that initialize everything to zero or NULL, etc. is a good way to get slow programs. Plus nobody, and I mean
nobody, can reliably write exception-safe C++ code that does anything tricky. Exception-safety in C++ is ridiculous and difficult. If you care about having correct programs, a much safer way to write them is to
turn exceptions off and write all of your code without them!
Anyway, for a programmer familiar with C it is very easy to use C++ as just a "slightly more convenient C". You can put little inline accessor methods in your structs, you can declare your variables in the middle of a function, and you can use a little bit of RAII style for some convenient things (such as profiling, or making sure a block of memory gets freed when exiting from a function that has a complex control flow). Sometimes it might make sense to use C++ templates a little bit, to reduce source code duplication (you'll still have near-duplicated code in the binary, but sometimes that is what you want, and templates might be less ugly than macros for your specific use-case.. it varies). For some kinds of code, std::vector is a much simpler way to get obviously-correct code than some manual malloc/free would be. Another pure win is std::sort, you can use it on ordinary arrays or std::vector or whatever else, and it will usually be faster than qsort() or anything else.
A big benefit of using C++ as a "better C" is that performance-wise, it doesn't cost any more than the equivalent C code. Be wary of constructors that initialize everything in a performance-critical struct (e.g. something you'll allocate a vector of thousands of, should have a do-nothing ctor or just a default ctor). Don't use STL (other than for convenience in non-performance-critical code), don't ever use the iostreams garbage, turn of RTTI and don't ever use dynamic_cast, and DISABLE EXCEPTIONS at least for your 32-bit builds. (In 64-bit builds the performance cost of having them enabled is pretty much zero, just a tiny bit of lookup-table bloat). Don't even use virtual methods unless you would have used some sort of dispatch anyways in your C code (but generally you should try not to use them in any performance-sensitive code). C++ is just as fast as C if you don't use any of the language features that have some extra cost. If you stick to "C subset" plus some conveniences like inline methods, then you can't really go wrong!
ilari wrote:And not all code has to be fast. In a typical desktop application only a very small percentage of the code is performance-critical.
This really varies with application domain. Its mostly true in computer chess, but (for example) mostly false in games. Modern games spend about 90% of their time spread across 50% of the code (millions of lines of it). Megabytes of code gets run every frame (30 or 60 times per second). So in games, we try our best not to write stupid-slow code anywhere, because it all adds up and you get a sort of "performance death by a thousand cuts". Example: we use our own container classes with the same API as the STL containers such as std::vector. However, they are implemented differently with the goal to
minimize generated code size because when you use thousands of different types with std::vector, off-the-shelf STL implementations generate literally megabytes of unnecessary code bloat, which makes the program run slower (due to paging, TLB misses, icache thrashing and so on). For specific use-cases like that, using some general-purpose library like STL is a good way to waste memory and CPU cycles.
Anyway, for computer chess, there are certainly parts of the program where performance is irrelevant (winboard/uci protocol stuff, top-level decision making etc.) but the "major" parts of the program such as evaluation and search do need to be fast. Move generation seems to be slightly less important, but to have a fast program you probably want that to be fast too. Code carefully, and understand the exact semantics of the code you write! I suggest not using a C++ feature unless you understand its performance consequences pretty well. Which really means, if you want to use a feature, try it out and investigate the performance consequences: is it slower than straight C? how much? Look at the generated assembly code. Is the compiler doing something stupid? A lot of people rely on the optimizer to just magically fix their code so it is fast. But there's two problems with that: (1) optimizers are really kind of dumb, plus the compiler implementer had to pick and choose what stuff was likely to be worth the CPU cycles at compile time, so even if they theoretically could do a certain type of optimization, that doesn't mean they actually do it. (2) sometimes language rules actually prevent the compiler from doing the "obvious" optimization. E.g. the possibility of pointer aliasing might prevent it from moving some loads and stores around. Even if you the programmer know that there is no aliasing, the compiler often has no way to know for sure so it ends up doing the "safe" thing.
