Earlier quoted context omitted.
If C gets operator overloading and RAII, there will be no good reason to use C++ for me!!
Is RAII in C a serious suggestion being made anywhere?
It is meaningless without destructors and exceptions.
Why I Write Games in C (yes, C)
451–460 of 556 posts
Re: Why I Write Games in C (yes, C)
#452Earlier quoted context omitted.
> it was generally non-deterministic This is basically it. People who have never worked on actual real-time systems just never seem to get that in those environments determinism often matters more than raw performance. I don't know about "soft" real-time (e.g. games, or audio/video) but in "hard" real-time (e.g. avionics, industrial control) it's pretty routine to do things like disable caches and take a huge perform…
Wow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.
There's probably enough jitter in the memory system and in instruction parallelism that accurate cycle counting will still be challenging.
Also, you probably want some padding so that newer versions of the CPU can be used without too much worry. It's possible for cycle counts of some routines to increase, depending on how new chips implement things under the hood.
[says a guy who was counting cycles, in the 1980s :-)]
Re: Why I Write Games in C (yes, C)
#453Earlier quoted context omitted.
Sounds very similar to NASA C programming guidelines. Each module during the initialization period would allocate its static memory size. Every loop had a upper bound's max iteration to prevent infinite loops. I think they posted the guidelines and it was a wonderful read about how they developed real time systems.
Do you happen to have a link to the guidelines?
Re: Why I Write Games in C (yes, C)
#454Earlier quoted context omitted.
> when you can implement the vast majority of C++ features in native C No, you absolutely cannot, even in principle. C++ is not "C with classes" and some syntactic sugar like it started out. That's not been the case for many years already. Also, even the features you can implement - you won't; you don't have the person-years for that. You will have to, need to, use libraries. For those you need to compare the librari…
So which feature can you not implement? The only I can think of which you'd have real problems are anonymous functions/lambdas. Most other features I think you can implement. It won't look the same, but it will serve the same purpose.
Destructors. It is the defining feature of the language; everything else in the language extends their reach. They are the key to full exercise of code paths, and thus reliable code.
A programmer who makes full use of destructors is simply a better programmer than one who doesn't.
Re: Why I Write Games in C (yes, C)
#455Earlier quoted context omitted.
And at the same time, I've heard people say "when it compiles, it works" about much weaker type systems, like Go's. It just seems to mean "this language catches more errors at compile time than the previous language I used."
> It just seems to mean "this language catches more errors at compile time than the previous language I used." That is a fair interpretation. I've programmed mostly in C# and Java because that's what was required at the time. I also know enough C and C++ to aim at my toes instead of the entire foot. So the comparison is between strongly typed imperative programming languages which are syntactically close to Rust. Als…
"Out of pocket"?
Re: Why I Write Games in C (yes, C)
#456Earlier quoted context omitted.
I don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?
> if these are transparent, no-performance-impact caches If there were no performance impact, there would be no point. I'm not just being snarky; there's an important point here. Caches exist to have a performance impact. In many domains it's OK to think about caching as a normal case, and to consider cache hit ratio during designs. When you say "no performance impact" you mean no negative performance impact, and tha…
While you might test your hard real-time requirements with caches disabled, there's still reason to run the code with caches afterwards.
E.g. errors that didn't match a branch or input scenario during testing which would go over budget without cache, but with cache might prevent a crash.
Another could be power consumption, latency optimization, or improvement of accuracy. E.g. some signal analysis doesn't work at all if the real-time code is above some required Nyquist threshold, but faster performance improves the maximum frequency that can be handled, improving accuracy.
Re: Why I Write Games in C (yes, C)
#457Anyone who is interested in secure, plain, well-written C-code should checkout the OpenBSD project. I've just been browsing through the code to brush-up on my C as it's been a few years since I've had to use C in anger, and it's a joy to read.
Whenever I look at BSD code, it reminds me of how we did everything in the '80s. There's an esthetic to stone knives and bearskins (check out "Primitive Technology" series on YouTube) but performance suffers on modern hardware.
Linux is irredeemably complex, and getting moreso all the time. My code nowadays bypasses it wherever possible -- O_DIRECT files, memory-mapped files, kernel-bypass NIC libraries that set up hardware ring buffers mapped into user address space.
Re: Why I Write Games in C (yes, C)
#458Earlier quoted context omitted.
> Even std::unique_ptr has runtime costs in release builds that a raw pointer does not. O RLY ? https://gcc.godbolt.org/z/QhbUjI
How would I create the pointer to int in the unique_ptr case without initializing the int? I tried this: https://gcc.godbolt.org/z/SfVxzU I expect there is a way, just I don't know it.
See the docs : https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...
For C++ ()` by `std::unique_ptr(new int)` (which with all explicit uses of `new` can end up not being safe in some cases (in that case, only if you've not enough memory to allocate an int which should not really be a common occurence...)
For C++ >= 20 you get std::make_unique_default_init which does that properly.
Re: Why I Write Games in C (yes, C)
#459> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
> The reality is you still have to free resources, so it's not like the garbage collector is doing work that doesn't need to be done.
This is quite blatantly false. The reality is that every single time your GC pass traverses an object but doesn't free it, it's wasting time doing work that didn't need to be done.
Re: Why I Write Games in C (yes, C)
#460I still believe that C++ is great because you can "use the good parts". To me the STL containers are good enough. It's always a balance between how much time you save, and how much performance you lose. C++ is good enough with this. The only lacking thing would be an object pool. The author writes > but so simple it's not too hard to learn to use it carefully. I would really love a replacement to C++, or an subset of…
Yeah I agree that there's still room for a "better C". Just C but with a few modernizations would go a long way.
I think Rust has a different lane: Rust is for when safety is absolutely important. C is for when you want very little abstraction between you and the hardware, and you just want it to do what you tell it.