It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).
Anyways, C++ is much easier to manage than any GC language for a real time application such as this. And your Rust "pun" is a rhyme.
http://fabiensanglard.net/doom3/index.php http://fabiensanglard.net/doom3/interviews.php#qc++
D or Nim (or even C!) would make more sense.
Surely there are better reasons to disregard Go for gamedev by now.
I keep wondering if it's not possible or if there's just not a lot of overlap between Go programmers and gamedevs? Wish someone knew.
Go users interested in diving in to SDL or OpenGL bindings to make a game shouldn't be discouraged. Lots of games are made in all sorts of high level languages, the heavy lifting is put onto a few native libraries. But if the goal is to make a general engine, I'd question its utility apart from fun/learning. Again there are game engines in high level languages (with dark native-level secrets in any that try to be performant) but they don't seem to get traction. Even an engine in e.g. C++ doesn't necessarily help your performance goals (http://www.yosoygames.com.ar/wp/2013/11/on-mike-actons-revie...) if your plan is to make it general instead of make it just support whatever sorts of games you're making and planning to make.
Better let the Unreal guys know about it then.
Also if one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.
If you never run out of memory you'll also never need to GC. ;) Or even free(), just let the program finish and reset the machine. (Actually not too weird in some embedded systems...) Some languages make it easier to not heap allocate than others, or notice when you are heap allocating. I hear Go does better than Java in this regard. But if you're facing a performance issue at the level where you're fighting the GC as the biggest barrier, and the language doesn't give you much assistance (like being able to choose latency/throughput tradeoffs or controls on non-determinism), that's a sign the language isn't that suitable for that performance problem domain. With performance sensitive games, you're already in the corner of having to worry about hardware details, so there's a strong incentive to just start the fight at the beginning without your hands tied by some language's static GC.
If fact, the majority of them gets abandoned even before memory pressure starts to be a relevant issue.
Even if Go isn't at the same level of D or Modula-3 in regards to memory management (heap, stack, global), it is already quite usable for many types of games.
As I mentioned in another comment a lot of fun games have been made in all sorts of languages. That doesn't really make any of them suitable for games though, and you'll still find far fewer examples of game engines in GC languages.
Game developers have a tendency to only update their tools when OS or console vendors force them to do so.
True, but just because a programming has language level GC, it doesn't mean it must be used everywhere.
If one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.
Also using value types is always an option.
One also doesn't call malloc() in such high-performance subsystems.
Rust, however is great.
Yet Go uses the oh-so-error-prone return value error checking that has been so successful in C :/
With Go you get a compiler error if you don't do something with that error. You have to explicitly decide to ignore it with `_`. As far as I remember that's quite different from C where you can get an error code, ignore it, and never realize you've missed it.
import "os"
func main() {
os.Open("this file does not exist")
}
Compare to Rust:
use std::fs::File;
fn main() {
File::open("this file does not exist");
}
warning: unused result which must be used
--> test.rs:14:5
|
14 | File::open("this file does not exist");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
Obviously this is not nearly as convenient as your Rust example, but enables some of its the benefits.
try:
...
pass