Optimisation is dead time. I swore I’d never do it. Nothing but scripting
languages, I swore. Garbage collection is not my business. Except, as it turns
out, CPU cycles aren’t free, and I want a lot of them. So, as long as I need
to make do with the slight resources available to me, I need to commit some
time to the occasional rewriting of inner loops in something a bit fast, with
decent libraries written by those yet more speed-obssessive than myself. for
my ends. C++ passes muster in this regard. I am typically rewriting inner
loops of python code using C++ at the moment, but maybe if i get some more
chops I’ll try some more recreational, creative applications - there are such handy tools for that, dontcha know?
Greg Sidelnikov’s OpenGL tutorials provide a sturdy,
non-nonsense example of practical C++ as a side effect of teaching OpenGL
(Compare his NeHe page
C++ is only tolerable with Boost, which has an excellent manual for modern C++ coding
Mark C. Chu-Carroll on C/C++ for numerical computing (“C and C++ suck rocks as languages for numerical computing. They are not the fastest, not by a longshot. In fact, the fundamental design of them makes it pretty much impossible to make really good, efficient code in C/C++. There’s a good reason that Fortran is still the language of choice for real, intense scientific applications that require the absolute best performance that can be drawn out of our machines.. Making real applications run really fast is something that’s done with the help of a compiler. Modern architectures have reached the point where people can’t code effectively in assembler anymore - switching the order of two independent instructions can have a dramatic impact on performance in a modern machine, and the constraints that you need to optimize for are just more complicated than people can generally deal with... So for modern systems, writing an efficient program is sort of a partnership. The human needs to careful choose algorithms - the machine can’t possibly do that. And the machine needs to carefully compute instruction ordering, pipeline constraints, memory fetch delays, etc. The two together can build really fast systems. But the two parts aren’t independent: the human needs to express the algorithm in a way that allows the compiler to understand it well enough to be able to really optimize it... And that’s where C and C++ fall down. C and C++ are strongly pointer-based languages. The real semantics of almost anything interesting end up involving pretty much unrestricted pointers.
Yossi Kreinin’s defective C++ (“some of [these] by themselves could be design choices, not bugs. For example, a programming language doesn’t have to provide garbage collection. It’s the combination of the things that makes them all problematic. For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective. Therefore, the problems are not listed in the order of “importance”... Instead, most defects are followed by one of their complementary defects, so that when a defect causes a problem, the next defect in the list makes it worse.)