Comment by anonnon
2 days ago
> And -fno-exceptions, while being de-facto standard e.g. in gamedev, still is not standard C++
So? The Linux kernel has freely relied on GCC-specific features for decades, effectively being written in "GCC C," with it only becoming buildable with Clang/LLVM in the last two years.
>(just look how much STL stuff
No one said you have to use the STL. Game devs often avoid it or use a substitute (like EASTL) more suitable for real-time environments.
> So? The Linux kernel has freely relied on GCC-specific features for decades
That is unironically admirable. Either they have their man on GCC team, or have been fantastically lucky. In the same decades there have been numerous GCC extensions and quirks that have been removed [edit: from the gcc c++ compiler] once new standard proclaims them non-conformant.
So, which C++ dialect would provide tangible benefits to a freestanding self-modifying code that is Linux kernel, without bringing enough problems to outweight it all completely?
RAII and templates are nice, but it comes at the cost of making code multiple orders of magnitude harder to reason about. You cannot "simply" add C++ to sparse/coccinelle. And unlike rust, c++ compiler does not really care about memory bugs.
I mean, the c++ committee introduced "start_lifetime_as", effectively declaring all existing low-level c++ programs invalid, and made lambdas that by design can capture references to local variables then be passed around. Why would you set yourself up to have rug pulled out on the next C++ revision if you are not forced to?
C++ is a disability that can be accomodated, not something you do to yourself on purpose.
> I mean, the c++ committee introduced "start_lifetime_as", effectively declaring all existing low-level c++ programs invalid
Did it? Wasn't that already the case before P2590R2?
And yes, a lot of the C++ lifetime model is insanity (https://en.cppreference.com/w/cpp/language/lifetime). Fortunately, contrary to the committee, compiler vendors are usually reasonable folks allowing needed low-level idioms (like casting integer constants to volatile ptr) and provide compiler flags whenever necessary.
Thank you for the correction! Indeed, the "magic malloc" part (P0593R6, a heroic effort by the way) looks to have gone in earlier into C++20. As you say, no sane compiler was affected by that change, the committee like a boss went in, saw everyone working, said "you all have our permission to continue working" and left.