Modern C++ evangelists

Hi all,

I wonder if anyone has any material I can refer people to when they start the modern C++ evangelist discourse?
To explain how modern C++ is bad and why, with numbers, evidence and whatnot?

Best regards,
Daniel

Edited by Daniel on Reason: Initial post
In short, no, there are none.

Programming is still more a craft than science, so there are no studies/evidence on different programming practices and long term results. Most of the "best practices" out there are specific to languages, opinion based and misleading at best.

The common starting point for people that have turned away from modern C++, OOP, design patterns and the rest is that they are skeptical of dogma and are willing to try different things to find what works best for them and why.

Generally speaking, a modern C++ evangelist is not skeptical of the claims modern C++ and the wider C++/OOP ecosystem make to be the One True Way (TM).

Having said that, something that might help is showing comparisons in Compiler Explorer or benchmarks of a modern C++ implementation vs a simple C one. This will only work, though, if someone is interested in reduced overhead and performance. Most of C++ claims tend to circle around high level concepts and ease of development, and overhead/perf sacrifices being generally acceptable.

My 2 cents.
Hi,

Not specifically "modern" C++ but this remembers me of this handmade chat (starting at 22'40) where Casey was asked about the Curiously Recurring Template Pattern and went on to implement a simple polymorphic copy function in four different ways (tagged union, RTTI, virtual functions and CRTP) showing how the C++ approaches resulted in much more convoluted code (although a C++ evangelist could surely argue that is biased)

There are two papers that come to my mind : this one is about energy efficiency across programming languages, and this one is about the usability of the factory pattern.

That said, there's not many serious studies on those issues because they are inherently difficult. There are objective metrics like speed and space that you can measure, but even then you are testing the programmers participating in the survey at least as much as the language. And then you have complex and partly subjective notions like maintainability, readability, etc., for which one can only find proxy metrics. You could e.g. count the number of bugs in a given project. But then, you only count the number of bugs found. And do easy bugs (like e.g. off-by-one) count as much as tricky ones (e.g. concurrency bugs manifesting only once in a while) ? ... So it is very easy to fall into biases or test the wrong thing. We are almost in social studies land, rather than computer science, and the difficulty to make this two disciplines work together is a big problem. But I wish there were more studies about programming practices.


Edited by Martin Fouilleul on