HN user
Hi, I decided to get back into C++ by making a project with a clear criteria. This project uses some C++17 features like structured binding so a modern-ish compiler is required.
This is my first Show HN post, so feedback and code review is more than welcome!
It does get easier to read and code over time. As an aside, the C++ in this post is pretty much as elegant as it gets.
Unreal's game-level memory management system uses reflection to implement garbage collection.
Yep. Game-level garbage collected C++. Which is exactly what I said, I just a didn't mention GC on C++ to avoid obscuring my point. I promise you the code at the game-engine-level is manually memory managed C++
You asked a question about the array and I answered it.
Yeah I missed the part where you said mmap. There's libraries that make that safer, but clearly there's a preference for working with the raw tools here.
Otherwise have fun with your own mental image of game programming yourself.
Ignorance is bliss. Have fun ignoring the progress systems programming has made in the last 30 years. Why bother even looking into it right? If what works for you works... that's all that matters.
What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping.
Guaranteed to be contiguous, and semantically equivalent to a C array in all cases.
If you don't trust your vendor's STL implementation take a look at the intrusive containers in EA's STL implementation. It's very very good for games. It's also safe, which is a good thing that doesn't obscure bugs it all.
https://github.com/electronicarts/EASTL
e.g. can the GPU read from it at all? Can it write? What are cache policies?
Fun fact, you can write your own template container with specific features with no additional overhead from a C "array" that's also memory safe.
if it starts deallocating at runtime it will take longer to fail).
It can't magically deallocate at runtime. It's deterministic. I don't think you understand you give up zero control. It's just a cleaner system with less room for human error.
obscuring bugs
What's obscure about knowing exactly where are all memory management occurs without exception? C-style malloc and free scattered all over the project is way more prone to hiding bugs.
I don't know anybody who would agree with this.
std::array<int,ARR_SIZE> is better than int arr[ARR_SIZE]
I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stubbornness to me.
Just to be clear, I am talking about destructor of an array
Can you be clear about why this is bad?
Why couldn't you use a structure to encapsulate the table and then have the destructor to deallocate the the array?
This is how vector works.
They do not have garbage collection. You're conflating game development with game engine development. When a big powerful, flexible, C++ engine has been written for you, you can use C# or JavaScript or BluePrints to use the engine to make a game.
Right, you use C++ to build game engines, you can use scripting languages on top of that once the engine is built.
Unreal and Unity were built using C++.
They offer garbage collected languages on top of their C++ game engines for scripting game logic. Any significant modifications to the engine will need to be done in C++
Can you give me an example of soft real time game that isn't hurt by the presence of a garbage collector?
It's gross because it's written in "C with namespaces and overloading"
Preferring #define for constants over constexpr is 100% the result of C++ bigotry.
It's a laughable decision. constexpr gives you the power of typesafe, compile time evaluation of purely functional expressions with type deduction. #define gives you a compile time 1972-style copy-paste
Do you know why Microsoft rewrote Minecraft in C++?
Games can certainly be successful in spite of performance problems, but why purposefully introduce them in the first place?
In the case of Notch, he used Java because he was most skilled at Java programming. The garbage collection, procedural generation, and multi-platform availability of the JVM allowed him to successfully release a massive hit as a solo indie developer.
At least that's one way to interpret it. Another way is that, had Notch been as skilled in C++ or (these days) Rust he could have made just as good of a cross platform game (even more so on mobile), that didn't concern itself with resource management outside of RAII and reference counting, was way more performant (no pauses), and in similar time frame as a skilled Java developer.
If you have a great idea use your favorite language. No doubt about that. You might be successful in spite of its specific deficiencies. However, if you are seeking a new language for a certain problem domain - like video games - choosing one with a feature that actively fights one of your fundamental goals (consistent framerate is only going to be a decision your users will regret you made.
It's funny that people like to say "users don't care what language it's written in". The fact that 8th graders know the the minecraft's garbage collector is a problem, suggests that using a garbage collected language for soft-realtime video games results in a seriously leaky abstraction.
Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have
This is the only part of the Jai philosophy I struggle to understand. How is an explicit delete keyword better than deterministic destruction? From my perspective, the former method reintroduces the problem the latter method solves.
Also, polymorphism is bad for games now? I absolutely cringe when I see abstract base classes, virtual functions and classical inheritance, outside of a generic interface in 2016. However, games might be the one case I would strongly consider using those features as part of my design. For example, a Final Fantasy-style job system seems to elegantly lend itself to the "Intro to OOP with C++98" style of runtime polymorphism*
As for exceptions, well I think the reputation of exceptions is one of the great tragedies of C++. Rust, Go, and other new languages seem to have decided that regressing to pervasive error checking boilerplate is more elegant than to have exception handlers.
I think Swift got it right with scoped exceptions and a defer statement - although, they selectively use "error handling" as double speak to avoid saying the e-word.
*Although, I personally think interface/protocol based solutions have proven to be the cleanest way to tackle polymorphism -- this is possibly true even in the case of an rpg with class inherentence as a game mechanic.