And wasn't it you who not long ago had to make a chance which required searching all over his code base to do because the thing you were changing was accessed from so many places?

yep, 99 code changes.

i'd have to check and see if that was due to an API change. its unlikely it was due to use of globals. i honestly have few or no problems working with globlas, perhaps because i'm used to their issues, and therefore don't do crazy things with them.

just checked it, the 99 changes was a new member variable added to both players and and NPC entities. it impacted almost every aspect of player and entity related code in the game. use of generic iterators would have reduced this. i added them when i made the changes.

but at the same time don't pretend it is in any way, shape, or form 'good practise' to do things your way because it simply isn't.

i don't claim it is. all i can say is that so far it has worked for me for my projects.

but again, this is not about how i do things, my question is about how other people do things, because what i was hearing (lots of allocations) was weird.

I think a lot of the confusion is stemming from the fact that the advocates of the static approach are creating strawman arguments and suggesting that any approach using the heap must be making frequent allocations every frame. This is clearly not the case. Almost all of us would look at pool allocators from preallocated chunks of memory for small objects that are going to be created and destroyed frequently. The point is that if my pool runs out of memory during use, I can increase its size (or, better, design it so I can add a new chunk of memory without affecting the existing chunks) which might have a performance penalty for that particular frame but then all continues as it was.

Taking away these strawman attacks, I can see absolutely no advantage to statically allocated memory. The idea that there is some kind of horrendous complexity associated with managing dynamic memory just suggests to me that people are writing C with classes and haven't embraced any of the "modern" (that term is stretched a little here) techniques that we use to manage it. That was certainly my impression from John Blow's video, where he presented the:

struct x
{
    Vec3 *p;
    int count;
};

pattern as an example of something that occurs frequently in professional production code. It is also my impression from the bits of the Caveman source I've seen, which is perfectly cool if it works for you, no problem. But it isn't "good" design.

Of course this approach works fine if you are happy to limit your resources to a predetermined amount. But to model it with dynamic heap allocation has, as far as I am concerned, absolutely negligable cost in terms of complexity and absolutely no cost in terms of performance, and removes all these completely unnecessary hard limits.

Yes, okay, every time you allocate memory, you have a "potential fail point". But so what? There are two possibilities here:

a) Your program can just exit when it runs out of memory. You catch std::bad_alloc at the top level of your program and show a dialog saying the machine does not have enough memory to run this game. This is not made easier by trying to allocate all the memory at startup.

b) Your program is controlling a nuclear power plant and must keep going no matter what. You have a system in place to free up other memory in std::set_new_handler or whatever, you have to track memory allocation very carefully and you need to deal with this. This is not made easier by trying to allocate all the memory at startup.

advocates of the static approach

i don't advocate any particular approach (except dynamic when size needs to be variable - obviously). i simply use static out of habit more than anything.

i was wondering what approaches other people use, because what i was hearing didn't seem right.

the only real benefit is it saves me a malloc at program start and a free at program end, and perhaps one machine instruction during access.

It doesn't save you a malloc/free at all -- It saves you having to write them in your source code, but the program loader still performs that allocation on your behalf. As I said, it probably coalesces all uninitialized data into a single system allocation, but you could do that too.

It also doesn't save you a machine instruction -- at compile time its not known what static address the memory will be located at, so you get a 'handle' to your data segment entities by their address, just as you would any other allocation, when the program is loaded -- The program loader won't go through the entire program to patch all your accesses with address literals. And as phantom says, that might even be worse than if those addresses were found in a more local scope due to cache locality -- but even still, even if there were an additional instruction to cost you something, the reality of modern hardware is that many instructions are effectively free because of instruction-reordering/super-scalar execution, and that the instruction windows are plenty big enough to make an optimal decision in this use case.

As I said, if its working for you, great, we're no one to argue that you should change; but again, I think we're trying to make it clear that you aren't gaining all that you think you are. It saves you having to type malloc and free somewhere -- that's it. What it costs you in terms of flexibility and in terms of logical structure has been pretty well addressed previously in this thread. I don't personally make the same tradeoff you are, even in small projects, but that's my mileage.

dislike of C++/STL and its implementation, absolutely no exceptions, a _very strong_ hate against OOP and "modern design

Fallacious appeals to authority aside, do these really sound like objective reasons to you?

Bear in mind engine programmers are the most experienced because they have been in the game a long time, so are likely to have learned their trade a long time ago. Such people can be resistant to change, then they make a video expressing their opinion and everyone runs round saying "My God, the guy that worked on X said it, it must be true".

Done correctly, code employing the "modern" or "OO" paradigms these guys are claiming to be bad, or a good implementation of the STL will map to pretty much identical machine code as the "do it yourself" approach when run through a good compiler.

Data orientation has to do with how you lay your data out in memory. It has nothing to do with the higher level language constructs you use.