[z0mbie42]

Hi, thank you for the pointers!

I try not to include C or C++ projects other than for educational purpose (like the Mandelbrot set) because one of my life's goal is to help the world to transition to a C & C++ free world (other than for kernels...).

I believe that my role is to promote projects which are "building the new world" and thus we need to abandon and port all form insecure core.

[sk0g]

So in an article about high/extreme performance systems, you're ignoring the vast majority of them because you don't agree with the tool used to achieve said performance? What..?

[pjmlp]

I guess because using other programming languages proves the point that there are other approaches, instead of reinforcing the status quo.

[z0mbie42]

Exactly this

[z0mbie42]

I believe that performance is irrelevant without correctness and security.

My opinion is that C and C++ can't bring enough security and correctness guarantees for mere mortals (lack of tooling, language features...).

Yes some correct and secure programs are written in C and C++ but it's not and will never be the norm.

[adev_]

By the sake of god, please stop to put C and C++ in the same basket when talking about security.

It just show you do not know what you are talking about.

Most security problems affecting C program DO NOT affect C++ programs.

Stack smash, vla abuse, string null termination problems, goto error control, double free corruption do NOT affect C++, they are C specific.

[pjmlp]

Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms.

Which is why Google has thrown out the towel and Android 11 will require hardware memory tagging for native code, and now everything is compiled with FORTIFY enabled.

Also Microsoft research shows otherwise, https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

> ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

So yeah, you are correct that C++ does offer the tools not to write C like security holes.

Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code.

[adev_]

> Unfortunately they surely do, because a large set of developers writes C++ code full of C idioms.

That's an other problem, not technical but educational. A lot of (older) programmer came to C++ passing by C and continue to use C in C++.

That need time, education and guidelines to change that... a lot of time.

Changing mindset and programmer education is sometimes harder than changing the program itself.

> Now you just need to convince a large spectrum of companies to actually stop doing C idioms while writing C++ code.

That is already ongoing. However do not forget that C++ has a bagage of 25 years of code pre-C++11 to upgrade before arriving there.

[pjmlp]

While I mostly agree, plenty of companies aren't going to change their coding, and outsourcing practices, until they hurt their button line.

[z0mbie42]

C++ is too large and huge to not shoot yourself in the foot (or of your user's) in one way or another.

[adev_]

This argument has been debunked 20 times already.

[pjmlp]

And 20 times more in security reports from Microsoft, Google and Apple.

[fermentation]

Despise of C and an interest in high-performance, a unique mix.

[pjmlp]

Back in the 80's C was anything but high performance.

Only with people willing to challenge the status quo do we move forward.

[beagle3]

It was always higher performance than e.g. Pascal or Basic on any relevant platform (the cost was lack of error checking, e.g. array bounds).

And it was slower than FORTRAN on most 32-but platforms such as DEC, Sun and IBM Unix workstations, VAXen and mainframes - but it was still the speed king on the most prevalent platform of the time, 8086/80286 and friends.

[pjmlp]

Only as urban myth scattered around by the C crowd.

As user from all Borland product until they changed to Inprise, it was definitely not the case. Pascal and Basic compilers provided enough customization points.

When one of them wasn't fast enough versus Assembly, none of them were.

I used to have fun showing C dudes in demoscene parties how to optimize code.

Now, if you are speaking about the dying days of MS-DOS, when everyone was jumping into 32 bit extenders with Watcom C++, then we are already in another chapter of 16 bit compiler history.

[beagle3]

I used TP from 3.0 to 7.0 and a little bit of Delphi 1, and contemporary Turbo C; I dropped to assembly often, dropped TP bound checking often, and was well aware of all these controls.

Parsing with a *ptr++ in TC was not matched by TP until IIRC v7; 16 bit watcom often produced way better code than either TP or TC.

And, as you say, indeed when speed was really needed, you dropped to assembly; no compiler at the time would properly generate “lodsb” inside a loop, although watcom did in its late win3 target days IIRC.

[pjmlp]

I cannot say I ever bother to benchmark parsing algorithms across languages in MS-DOS, so maybe that was a case where Turbo C might have won a couple of micro-benchmarks.

[BubRoss]

This doesn't line up with the reality that almost all games were written in combinations of C and asm.

[pjmlp]

During 8 bit days, all games that mattered were written in Assembly.

During the 16 bit days, Pascal, Basic, C, Modula-2, AMOS were the "Unity" of early 90's game developers, with serious games still being written in Assembly.

The switch to C occurred much later at the end of MS-DOS lifetime, when 386 and 486 were widespread enough, thanks success like Doom and Abrash books.

Easy to check from pouet, hugi, breakout, Assembly or GDC postmortem archives.

[z3phyr]

In my opinion, we should instead focus on hardware and experiment more with different kinds of cpus, memory, co-processors etc. The key to newer software systems are newer kinds of hardware, for which you can write newer experimental systems in the language of your own designs.

The sky is the limit, and there is so much to do! Transactional memory, massively multicore computers, hardware built on predicate logic, neuromorphic computers, and whatnot.

We are still mostly stuck with the cpu and memory designs of old.

[hedora]

Some of the most secure software is written in C.

The language matters less than you’d think once you get past a certain correctness baseline.

[z0mbie42]

I have not doubts that secure software can be written is C, but it's not the norm and it's too easy to introduce vulnerabilities in C for mere mortals.

[bityard]

I mean, have you even _seen_ the trail of CVEs that Java has left in its wake over the past few decades?