u/kevinnnyip

https://preview.redd.it/sy55a9dbp5bh1.png?width=2427&format=png&auto=webp&s=ac8289e3635986c9243b86f498e132817bcecd93

So I heard a while ago that C# will be moving to GDExtension instead of sticking with the current scripting approach, so I decided to clone godot-dotnet from this repo: https://github.com/godotengine/godot-dotnet for GDExtension, which is currently a work in progress. The workflow doesn't seem too bad technically I can streamline the build process so it automatically generates and copies the GDExtension into the Godot game project folder. The problem is that if you do this while the Godot editor is running, it crashes the editor and you have to reopen it. So if you add a new class and switch to the editor to add it there, it just won't work.

Debugging is also kind of impossible right now, even if you use a breakpoint in the inspector instead of just printing, since as shown in the picture I attached above there's basically no way to tell what's what. That's kind of expected since it's native code, though. I know C# GDExtension is still a work in progress, but I really hope they iron out these issues, because right now, in terms of game dev overall, it's actually worse than what we currently have with these problems.

So from my general understanding, the sole reason we have L1, L2, and L3 cache memory on a CPU is to solve the latency problem of accessing data from the CPU to RAM. The cache exists to prefetch series of instructions and hold whatever local data is being referenced nearby. The key thing is that with contiguous memory, the CPU can just do pointer arithmetic and jump straight to the exact memory address it needs without having to wait on RAM.

But due to the nature of OOP, if a single class has a lot of fields that are pointers to a bunch of other things, we end up having to wait on RAM constantly. Because of how heap memory works, all that data gets scattered across random addresses and is only held together by a chain of pointers.

So do we actually have another way around this problem or do we need to ditch OOP altogether and go data oriented? Could we invent or implement a compiler smart enough to interpret and parse all heap allocations into a single contiguous block of memory as much as possible? And if that cannot be done, can we just make cache sizes so large that they can hopefully hold all the important addresses at once?

So per title why doesn't C++ have a ptr<T> syntax of smart pointers for raw pointers instead of T*?

Most of the time the * syntax is ambiguous and hard to read. For example, array of pointers vs pointer to array looks almost identical:

char* argv[]    // array of pointers
char (*argv)[]  // pointer to an array

You have to mentally parse a spiral rule just to tell them apart. Compare to what it could have been:

array<ptr<char>>   // array of pointers 
ptr<array<char>>   // pointer to array

So why didn't C++ standardize aptr<T> alias for raw pointers too? Is it purely backwards compatibility or is there a deeper reason?