Agreed, simplicity is the key. But it ain't the motto of a handful of coders out there.

Writing a big pile of code is one (easy) thing, summarizing it another (feasible but many just don't bother).

Aybe One said:
After 30 years of service, my CRT resigned… Haven't been able to fix it and these servicing shops are no more… I don't like that I'm going to have to throw it away because it's still in pretty good shape otherwise…

Maybe you would meet a guy with necessary skills in the future. My basement is full of working and broken CRTs. ; )

I really wonder why CRTs seem no longer made. So many people whine about how much better they were.
Afaik, currently they sell more vinyl records than compact discs, so here the retro tech has survived.
Maybe those CRT tubes are really hard to manufacture.

taby said:
nothing more than vector, string, and map.

But reducing to those does not stop them to use modern syntax i can not read. : )

If you rely on void pointers in C++, then you're not doing it correctly 95% of the time.

Surely you're not advocating the use of void pointers (e.g. say, home-brewed linked lists) over things like templates and the STL’s list container? This constitutes a non-zero failure amount, and so I didn't bother trying to understand the rest of your logic.

Even then, one doesn't really need void pointers, even when constructing a container that is not already supplied by the STL, such as a Huffman tree:

https://github.com/sjhalayka/qc_for_cs/blob/main/pd_10_3_2.cpp

taby said:
Surely you're not advocating the use of void pointers (e.g. say, home-brewed linked lists) over things like templates and the STL’s list container?

I always implement lists myself. STLs list containers are slow AF and thus useless for performance critical realtime apps in my experience.

Which may still apply to STL as a whole.
A decade ago, STL for gamedev was considered a no-go due to bad performance.

Has this changed? And if so, why? Is current HW so powerful we can just waste it?
Seems not, as performance issues are seemingly the main concern and critique on recent games.

This question bothers me a lot. After years of tools development, i became very used to STL and the comfort.
But observing performance i get impressions on both ends. Sometimes using std::vectors with dynamic size seems faster than expected, but often it's still a total performance killer. Allocation and deallocation costs seem still way too high to use it for realtime, and once we implement custom memory management, i don't see much reason to still use STL at all. But not sure.

@JoeJ You see, I was led to believe that Unreal Engine has its own containers mostly because STL vector was not guaranteed to use one contiguous block of memory. That was rectified long ago.

I also wonder about the facts, pertaining to the lumping of all STL implementations into one pile. That’s a pretty broad brush that you’re using.

JoeJ said:I always implement lists myself. STLs list containers are slow AF and thus useless for performance critical realtime apps in my experience.

STL “list” (if that's what you mean) is slow because it's a linked list, which in itself is slow on current hardware. You cannot practically implement a linked list that is considerably faster than what STL does. If you use an array, that's not a list, thus a different container, so you cannot compare them.

JoeJ said:Has this changed? And if so, why? Is current HW so powerful we can just waste it? Seems not, as performance issues are seemingly the main concern and critique on recent games.

No, it's because STL at the current state is almost identical in terms of performance, due to both advancements in the STL as well as compilers. Consider the following case, using both a dynamic C array and a vector:

https://godbolt.org/z/YYjPKT9P7​

The STL-vector produces a bit more ASM code, but it's not to a point where a difference could even be measured (it's mostly outside the loop). So for all intents and purposes, the std::vector is as fast as the C array. There are some differences, still - I employ my own Vector, mostly to add some optimizations here and there (things like adding elements without initializing them, which can make a difference for very large sets). But for the average users, using their own “vector” will not add anything of value compared to using STL. Performance-issues in current games are mostly to GFX, which mostly has nothing to do in the remotest with the CPU-execution speed, especially not if you are using a std::vector or my::Vector to store some objects.