Given the universality of C++, everyone effectively ends up writing in their own dialect and there is a sizeable faction that uses it as "C with Classes" and "C with templates". So there is a lot of C++ projects that explicitly steer clear of modern C++ features, especially derived from the mother of all unholy abominations and the manifestation of everything that is wrong with the modern C++, the boost library.

Give or take.

Usually those are the projects where CVEs are a common feature..

They are also the projects that get the most attention. I wouldn't rule out that python/javascript/whatever projects have just as many, if not even more, security flaws than your typical widely-used C library. They are just not interesting enough to warrant the required attention. The flaws are likely to be more subtle than simple buffer overflows too, think of all the abstractions involved.

My point was "C with Classes" and "C with templates" versus modern C++ best practices.

C++ code can be quite safe, providing people stop writing C with C++ compilers.

... as are the projects that overdo on "modern C++" to the extent of introducing even more severe problems masked by the layers of needless abstraction.

CVEs don't come from C or C++. They come from the lack of coding discipline and with all other things being equal C programmers are generally better skilled and more diligent than their C++ counterparts.

> C programmers are generally better skilled and more diligent than their C++ counterparts.

That is not what the CVEs on Linux prove.

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

One would expect, on a C project with the rigor of review process that patches go through and the usual assement I keep hearing since the early 90's about C programmer skills, now repeated again by you, that Linux would have 0 CVEs reported.

The majority of exploits in C++ are related to its copy-paste compatibility with C, and devs that insist in using them in spite of the language offering safer, better, alternatives.

> That is not what the CVEs on Linux prove.

You picked one of the largest, complex and most scrutinized C projects of the whole time and compared its CVE count... to what exactly?

Exactly because it is "largest, complex and most scrutinized C projects of the whole time" and yet it is impossible to use C without producing a couple of CVEs every single month.

And a good example against the myth that the skilled C programmer that doens't produce memory corruption exists.

> Exactly

Again - what are you comparing Linux CVE counts to?

You can't point at an absolute count for A while arguing that A is inferior to B. I see nothing to support the assumption that a Linux-sized project in C++ would've have any less of CVEs.

> the myth that the skilled C programmer that doens't produce memory corruption exists.

Don't put words in my mouth. You are refuting a point that I didn't make. I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

> I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

So where are those statistic results available?

Every single memory corruption in C++ code can be traced back at language semantics inherited from C, thus common to both languages.

Which aren't present in C++ code bases where developers adopt C++ best practices, meaning eschewing the majority of C programming pattern, while adopting std library types, references instead of pointers, class enumerations instead of plain enums, classes to keep struct invariants, ....

History has proven on its CVE databases that the majority of C devs are not skilled at all to care about writing safe code.

Whereas one of the major points done by ANSI C++ members work is how to reduce UB use cases and reduce the possibilities of exploits, the ANSI C members decided to turn ANNEX K into an optional item in C11, and VLAs have been proven to be quite nice for stack attacks, thus not even considered for ANSI C++ adoption.

Compile time is a pretty big reason.

so do you also not use std::unordered_map, std::shared_ptr, std::thread, std::regex, or std::mutex ? because they all come from boost.

I used boost extensively in the past (2006-2011). But I have been disillusioned by all the accidental complexity. It's easy to use the complicated parts of boost, but you lose sight of the inefficiencies you introduce all over the place, be it code bloat, unnecessary indirections, splitting up of allocations, or merely bloating your build times.

Besides, std::unordered_map is flawed, the bucket interface forces suboptimal cache behavior. std::thread is such a thin abstraction, if you use C++ you might as well use it but it doesn't buy you much. same with std::mutex. std::regex on the other hand I avoid because it's easy to write "regular" expressions that cause backtracking with it. I would look at something like re2 instead, if I had to deal with text parsing a lot. or a proper LALR parser generator if the language is not regular.

Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use. You can also be more confident in their future stability.

> Once they're safely out of Boost and implemented by the stdlib they're an order of magnitude more convenient to use.

I don't understand this. Most of the time the API doesn't even change; you can just do `namespace lib = std` or `namespace lib = boost` according to which one you want to use. In my own code for instance I have a header where I choose the std::, std::experimental or boost:: version of `optional`, `string_view`, and `any` according to the recentness of the stdlib I'm using; nothing else is needed.