Jack London once said, "You can't wait for inspiration. You have to go after it with a club". When it comes to game development, the SDL project may well be such a club. How is it made, though?

What bugs does SDL have? And what Sam Lantinga says about it?

https://pvs-studio.com/en/blog/posts/cpp/1081/

@cppguide
@cpp
@c_discussions

C++ trick I pulled today. Like an explicit constructor but context dependent. Any alternatives from folks who've needed to do similar? One thing I still need to dig into a little deeper is how copy elision behaves here.

An excellent talk by Timur about type punning, the UB weirdness that accompanies it and attempts at doing something similar with modern C++ without UB (which led to std::bit_cast and other proposals) while revisiting notions like aliasing and alignment.

If you're writing code that's doing lots of memory allocations (e.g. lots of nodes being created in some huge graph at runtime and/or you're also doing lots of type erasure, and most importantly you can't know in advance how many you'll need) then you might wanna take a look at C++17's std::pmr instead of trying to write your own allocators (which is still a good idea if the goal is just to learn).

In particular, what would interest you the most are the memory resources themselves, which are in the memory_resource header file (https://en.cppreference.com/w/cpp/header/memory_resource ).

I had great success using in particular unsynchronized_pool_resource (perfect in single-threaded settings where you're sure you don't want other threads to access that resource) and monotonic_buffer_resource (perfect when you don't care about reusing previously freed memory and care more about speed, so that the cost of one allocation is then just a pointer increment inside a buffer and "deallocation" is a no-op) in our production code and, depending on the scenario, achieved speedups between x2 and x3 compared to using the standard allocator.

You can directly use the .allocate and .deallocate member functions of those resources (although the semantics will be a bit different from your usual malloc and free, as you need to remember the alignment and the size of the allocated space when you want to deallocate). You also have standard containers inside std::pmr that can be bound to one of those memory resources in a type-erased way (hence the "polymorphic" in the name), like std::pmr::vector or std::pmr::list.

There's also an awesome CppCon talk by John Lakos in two parts which explains those allocation strategies:

• part 1: https://www.youtube.com/watch?v=nZNd5FjSquk
• part 2: https://www.youtube.com/watch?v=CFzuFNSpycI

TL;DR

At last the experiment is over, and CMake 3.28 has official support for C++ 20 named modules enabled without having to set the CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API variable.