And C++ supports recursion, immutability, and the other hyped features of functional programming.

Yes, and at this rate, perhaps in another 20 years, it will have caught up with LISP (from the late 1950s).

And if you aren't a dumbass, you'll use ...

A simpler, more efficient high-level (higher than C++) language that is more expressive with fewer lines of code, less prone to introducing silly bugs caused by human error, and more readable by other programmers.

C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.

C++ is for conformists and trend-followers lacking in enough critical thinking skills of their own to investigate and adopt better tools for the job.

That's what it is.

The end of quarter profit is what matters. Suck it up and take it like a man! Pull your weight like a true team player or you'll be let go to make way for a flexible, empowered, dedicated business-oriented go-getter from the thousands of them queuing up at the door.

If you can't do it right, or don't like it, get out. Don't drag the team down with you, loser.

Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform

Different compilers on the same platform find different bugs (warnings, errors).

Different static analysis tools also find different defects.

Different numbers of CPUs/Cores find different timing bugs, deadlocks, race conditions, corruption etc. on concurrent code.

Different binary architectures show up endianness bugs and subtle corruption bugs due to alignment of data in memory.

Different OSs find different run-time behaviour problems and dependency problems. They also find problems in any OS abstraction code.

The more compilers. analysers, machines, architectures and OSs you use, the more bugs you find, and the more bugs you find and fix, the higher the quality of your product.

It's always easiest to develop on top of a high-quality code base. That's when you're fastest.

You don't need a QA department. Automation can get you 80-90% of the benefit.

You don't need to do everything all at once. Start adding new tests, builds and platforms as you go, a bit at a time. You should see your velocity increase very soon.

C and C++ were designed on the principle that the fundamental language constructs should be as fast as possible.

C was designed to be as simple (and flexible) as possible. It (the compiler) had to run on tiny machines, by modern standards. Speed (of the object code) is a consequence/coincidence of the simplicity of the language and the fact that simpler languages tend to produce tighter (and faster) object code when compiled.

C's simplicity can be summed up by the following rule of thumb: if something can be calculated at compile time, the language usually supports it. Everything else (like handling array dimensions and strings) are left up to the programmer.

When computers were small and slow, C was ideal for programming them when FORTH wasn't big enough.

c++ is great.

Keep repeating it often enough and people will believe you.

A build system can help you modularize your build so that a complete recompile does not occur after a syntax or linker error.

For C++? Are you nuts?!

What you should be doing outside the CS class and in the so-called "Real World" is "being productive". That usually means screw the warnings, it has to be completed ASAP or we'll find someone "more productive" than you are.

I'm having a sense of humour failure at the moment, so apologies if this was not taken in the spirit it was intended but: that sort of attitude tends to get you eaten by the Real World for breakfast.

I've very recently found myself working for a company that has gone in that direction due to incompetent management and greedy VPs. I and my colleagues have been pressure into fixing bugs with no proper bug report, no access to the production hardware and no integration and test facilities "by lunch time" with all the corner-cutting that implies.

The company is now paying for it, and I am on the verge of accepting a new job with another company.

I don't think you understand the study

I didn't RTFA because I could tell from the summary that it was a lot of nonsense.

or c++

I understand enough about C++ to know to avoid it wherever possible. I freely admit that my brain isn't big enough to fight against C++ with enough perseverance to get it to do anything useful correctly. I'll stick to C and scripting languages thank you very much.

or unit testing.

*cough* Test Driven Development *cough*

To become half way good at C++ you either need to devote you entire life to it over decades (somewhat like a monk) or have an IQ of at least 200. Life's too short and my IQ is miles too low.

Why not just say that you should always build against the latest official working source before checkin? It has nothing to do with unit testing.

It does. You shouldn't be putting in new logic bugs with your deliveries. The code should compile cleanly and you should do due diligence to avoid putting in new bugs.

Bugs are expensive to fix, in terms of debugging time and refactoring of broken code to change additional changes built on top of the broken code.

It's amazing how much real progress you can make if you follow these simple rules.

And of course everyone always builds with the same configuration, same compiler, on the same platform.

Yes, they should, and it should be scripted so that it's trivial so that there's no excuse for not doing it every single time.

Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network. There should be enough network, storage and CPU capacity to make the builds quick so that there is no excuse for not doing them.

How does a unit test prevent a build error?

Because you have to build your code to run the unit test. The two are (should be) intimately linked. And you should always be building against the latest official working source from the upstream repo.