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.

When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.

You should be compiling with warnings as errors as soon as you start coding, and you should fix each one as they occur before you move on to write the next line of code.

Putting off fixing these problems leads to bloated and fragile code and wastes much more time debugging and fixing later.

I worked on features that let Visual Studio talk to SAP.

Well, that explains the rest of your post.

what part of this am I not getting?

It's a sign of the times.

Most people just do a "sudo apt-get install" now or click on "Install" in the update manager.

FOSS is mature in that it has a boring, straight-laced, conformist main-stream that caters to 99.9% of the public's needs with unsurprising conventional applications.

We have become institutionalised and the cutting edge has been blunted.