Everything wrong with C++.

jtsn · 06-25-2026, 05:43 AM

Quote:

Originally Posted by why_bother

Funny you mention cache misses; I was reading something on another forum about game development where there was a comment that said something to the effect of storing certain data in contiguous memory (ie. arrays) to avoid cache misses. Otherwise and as you say, your game would be very slow because of constant cache misses.

Game development is more severely affected by its soft realtime requirements. However the general principle applies to all software.

For example for a spreadsheet you could use the traditional architecture of an array of unions (storing data of different types at the same place) and quickly load the data of adjacent cells into the cache for processing.

Or you can build a sophisticated "Cell" -> "Number" -> "Currency" whatever class hierarchy then iterate through them like described in the OOP 101 textbook. The latter will just perform a lot worse, because OOP is not a design pattern that is very friendly to real-word hardware. This reality in 2020s "office" software is the main reason it requires 1990s supercomputer-tier hardware to perform the most basic tasks which were already implemented in 1980s software.

Quote:

I suspect that concern about "cache misses" qualifies as "bleeding edge."

It's about "getting the job done". Memory latency hasn't improved for decades, so when your code trashes caches with "hidden implementation details" and subsequently waits for memory access, it will perform like the 1980s before caches became a thing. While "big business" can just make users wait in front of their computer until their contraceptions have sorted themselves out, video game developers need to deliver their data processing at a reasonable speed, because their results show up on the screen in realtime. That's why they simply care about it more not "hiding the implementation details".

pan64 · 06-25-2026, 05:54 AM

Quote:

Originally Posted by jtsn

Or you can build a sophisticated "Cell" -> "Number" -> "Currency" whatever class hierarchy then iterate through them like described in the OOP 101 textbook. The latter will just perform a lot worse, because OOP is not a design pattern that is very friendly to real-word hardware. This reality in 2020s "office" software is the main reason it requires 1990s supercomputer-tier hardware to perform the most basic tasks which were already implemented in 1980s software.

This is not a problem with OOP, but with the actual implementation design. OOP does not prevent you from writing fast/good programs.

EdGr · 06-25-2026, 06:41 AM

One just needs to be careful. There is often an additional level of indirection, and constructors and destructors need to be fast in a large array of objects.
Ed

dugan · 06-25-2026, 09:21 AM

Quote:

Originally Posted by jtsn

Or you can build a sophisticated "Cell" -> "Number" -> "Currency" whatever class hierarchy then iterate through them like described in the OOP 101 textbook.

Absolutely nonsense. The OOP 201 textbook recommendation for implementing a spreadsheet cell would be to use Flyweights. And that is, in fact, how Google Web Toolkit did it.

Also, using video games to argue against OOP is silly in the extreme. All of the modern game engines use OOP heavily.

wainamoinen · 06-25-2026, 01:02 PM

Quote:

Originally Posted by dugan

Also, using video games to argue against OOP is silly in the extreme. All of the modern game engines use OOP heavily.

Game engines use C++ classes and some of its features, but they don't follow strict OOP. This video has very interesting insights of why:

CppCon 2014: Mike Acton "Data-Oriented Design and C++" https://www.youtube.com/watch?v=rX0ItVEVjHc

When you care about high performance you may use data-oriented design instead of OOP design patterns. Why? because hardware matters! These videos are about this:

CppCon 2018: Stoyan Nikolov "OOP Is Dead, Long Live Data-oriented Design" https://www.youtube.com/watch?v=yy8jQgmhbAU

CppCon 2025: Vittorio Romeo "More Speed & Simplicity: Practical Data-Oriented Design in C++" https://www.youtube.com/watch?v=SzjJfKHygaQ

dugan · 06-25-2026, 01:19 PM

Quote:

Originally Posted by wainamoinen

Game engines use C++ classes and some of its features, but they don't follow strict OOP.

Which is appropriate, since C++ is a multi-paradigm language and not a pure-OOP language.

pan64 · 06-26-2026, 02:03 AM

Quote:

Originally Posted by wainamoinen

When you care about high performance you may use data-oriented design instead of OOP design patterns. Why? because hardware matters![/URL]

In short yes, if you want direct access to the hardware and do that as fast as it is possible you will need to implement everything carefully, and avoid any unnecessary internal steps (like calling class constructors, .... go thru different layers). Anyway, that works only on a fixed hardware data structure, which is built/detected during the startup of the process.

jtsn · 06-26-2026, 03:59 AM

Quote:

Originally Posted by wainamoinen

When you care about high performance you may use data-oriented design instead of OOP design patterns. Why? because hardware matters! These videos are about this:

CppCon 2025: Vittorio Romeo "More Speed & Simplicity: Practical Data-Oriented Design in C++" https://www.youtube.com/watch?v=SzjJfKHygaQ

Excellent demonstration of the inherent runtime overhead of C++ OOP. Back in the days of Cfront that was still visible to the programmer, nowadays everyone trusts their (failing) compiler magic, because nobody looks at the compiler output.

Quote:

Which is appropriate, since C++ is a multi-paradigm language and not a pure-OOP language.

Several compiled languages are heavily advertised by their stakeholders with "zero cost abstraction", which has been pretty much debunked now.

At the other end of this pipeline end users desperately throw CPUs with 3D-NAND cache to shoulder the overhead of a paradigm constantly fighting the hardware, the one paradigm C++ was initially created for. And that affects every software and wasted terawatthours of electrical energy for some "zero cost abstraction" that never existed in the first place.

pan64 · 06-26-2026, 04:28 AM

Quote:

Originally Posted by jtsn

Excellent demonstration of the inherent runtime overhead of C++ OOP. Back in the days of Cfront that was still visible to the programmer, nowadays everyone trusts their (failing) compiler magic, because nobody looks at the compiler output.

No, that's a mistake again. It's not about the runtime overhead, it's about the price of flexibility. If you want to write code that runs on any hardware, you have to create layers, callbacks, virtual function tables that allow you to use the same C++ code anywhere.

If you want to make it really, really fast, you have to skip those things and connect directly to the hardware, which means you can't use this generalized structure. But again, that's not a problem with OOP, it's a question of design: do you want to be fast or do you want to be generic?

jtsn · 06-26-2026, 05:21 AM

The C++ mistake already started in 1985 with replacing malloc() with new. This is not how to use a heap. It wasn't in 1985 and doesn't change by sugaring it with std::make_unique today. It just didn't cost as much on a 1985 i386, it just idled less waiting for scattered memory accesses than ANY current platform does (yes ANY hardware existing under the sun is SLOW with textbook C++ OOP today).

Vittorio Romeo perfectly explains that and then basically rebuilds his example into a 1970s K&R C program. The design patterns aren't his new inventions, they are all 1970s pre-Smalltalk, pre-SIMULA.

pan64 · 06-26-2026, 06:05 AM

Quote:

Originally Posted by jtsn

The C++ mistake already started in 1985 with replacing malloc() with new. This is not how to use a heap. It wasn't in 1985 and doesn't change by sugaring it with std::make_unique today. It just didn't cost as much on a 1985 i386, it just idled less waiting for scattered memory accesses than ANY current platform does (yes ANY hardware existing under the sun is SLOW with textbook C++ OOP today).

Vittorio Romeo perfectly explains that and then basically rebuilds his example into a 1970s K&R C program. The design patterns aren't his new inventions, they are all 1970s pre-Smalltalk, pre-SIMULA.

new is not a replacement of malloc, but an enhanced version for classes. And honestly, one of the biggest problems with C++ is memory management, which the user (developers) should have done. It soon turned out to be very difficult (for them). That gave rise to Java, where it all happens automatically.
And it is still not a problem with OOP.

jtsn · 06-26-2026, 06:16 AM

C++ started das Cfront, a frontend for C compilers. The new statement thought out in the ivory tower was turned into a call of malloc() and delete into a call of free(). That's the reality and it is still sitting inside millions of LoC of legacy C++ software in real world production.

Malloc()ing single objects off the heap was always the worst design pattern for any real-world hardware back then and now. And yet it became part of the C++ programming language (!) (not even standard library, the language itself) and every single C++ textbook.

why_bother · 06-26-2026, 08:27 AM

Quote:

Originally Posted by jtsn

Game development is more severely affected by its soft realtime requirements. However the general principle applies to all software.

For example for a spreadsheet you could use the traditional architecture of an array of unions (storing data of different types at the same place) and quickly load the data of adjacent cells into the cache for processing.

Or you can build a sophisticated "Cell" -> "Number" -> "Currency" whatever class hierarchy then iterate through them like described in the OOP 101 textbook. The latter will just perform a lot worse, because OOP is not a design pattern that is very friendly to real-word hardware. This reality in 2020s "office" software is the main reason it requires 1990s supercomputer-tier hardware to perform the most basic tasks which were already implemented in 1980s software.

It's about "getting the job done". Memory latency hasn't improved for decades, so when your code trashes caches with "hidden implementation details" and subsequently waits for memory access, it will perform like the 1980s before caches became a thing. While "big business" can just make users wait in front of their computer until their contraceptions have sorted themselves out, video game developers need to deliver their data processing at a reasonable speed, because their results show up on the screen in realtime. That's why they simply care about it more not "hiding the implementation details".

I don't know what you have against the OOP paradigm (and/or possibly C++ itself), and while I'm not saying it's the answer to everything; I really don't believe that one would only use C++ just for the sake of std::string. Particularly when std::string isn't a part of the base language, and therefore is not actually a type like it is in other languages, and as far as I know, I believe it's actually implemented in C++'s standard library. And furthermore, it's actually implemented using a character array "under the hood", and therefore would really just be window dressing for what's really just an easy to use character array.

I'm willing to bet if I were to look at the source code for the original Grand Theft Auto (that was written in C++ I believe), I would see classes, constructors, etc. I'd also be willing to bet that, and as dugan points out, if I were to do the same with most, if not, any modern game engine, I would also see classes, constructors, etc, and not just a bunch of standalone functions (like you would have in C).

So I do have to agree with both pan's and dugan's comments:

Quote:

Originally Posted by pan64

This is not a problem with OOP, but with the actual implementation design. OOP does not prevent you from writing fast/good programs.

Quote:

Originally Posted by dugan

Absolutely nonsense. The OOP 201 textbook recommendation for implementing a spreadsheet cell would be to use Flyweights. And that is, in fact, how Google Web Toolkit did it.

Also, using video games to argue against OOP is silly in the extreme. All of the modern game engines use OOP heavily.

I think they have it right.

I also don't see how the hardware would care what paradigm you're operating under, be that OOP, be that procedural, or whatever else.

I can see how arranging the data would affect cache memory, so I do believe you have a valid point there, all that said.

jtsn · 06-26-2026, 08:36 AM

Quote:

Originally Posted by why_bother

I'm willing to bet if I were to look at the source code for the original Grand Theft Auto (that was written in C++ I believe),

There was no C++ compiler available for the the OG PlayStation in 1996.

You obviously lack background knowledge to contribute anything substantial to the discussion.

Quote:

I think they have it right.

Why should I even care about who you think have it right?

why_bother · 06-26-2026, 08:44 AM

Quote:

Originally Posted by jtsn

There was no C++ compiler available for the the OG PlayStation in 1996.

You obviously lack background knowledge to contribute anything substantial to the discussion.

Why should I even care about who you think have it right?

Not sure why you feel the need to be hostile, but I know for a fact the original Grand Theft Auto had a PC version, because I remember playing it on a PC (a 286 if I remember right). So what does C++ compiler support for PlayStation's have to do with anything?

I think you've got it the wrong way around - you're clearly the one lacking background knowledge, and clearly not just going by post #74 either...

Can't handle it when people don't agree with you? Well you might not want to post on a forum like this one in that case, just say'n...