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. : )

taby said:
Bullshit. LOL 95% of all coding problems require nothing more than vector, string, and map.

You spelled void* wrongly.

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

You didn't say anything about doing it maintainable way.

Note: I'd still state that using void* can be correct 100% of the time - correct means that given algorithm runs and does its purpose over the data that is supplied. Which it can, without any problem. Whether that is maintainable is another topic.

Note 2: I'd still oppose the statement that vector, string and map are 95% of all coding problems - at least as a bit misleading. Data structures are helpful and big part (there is more of them - incl. graphs, trees, stack, queue, etc.), another big part are algorithms - often over the data stored in those data structures (sorting, etc.).

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.

My point is that there is difference between correct and unmaintainable (in definitions). Which you'd realize if you read through both my notes (and you'd also see that I'm hardly advocating for using void pointers everywhere).

@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.