Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
libCat
🐈⬛ A runtime for C++26 w/out libC or POSIX. Smaller binaries, only arena allocators, SIMD, stronger type safety than STL, and value-based errors!
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
but theorem provers can write real world programs: https://github.com/jdublu10/pacman :)
This doesn't have to be true. Over the past year I've made progress towards demonstrating how even non-freestanding C++ can be written without any C or C++ standard library headers or DLLs (with large benefits). There are a few names which the compilers require to be in the std:: namespace, though, but they're very special features like source_location and construct_at with semantics that can't be expressed otherwise.
For instance, maybe I'm just overestimating how verbose C++ would have been, or maybe I managed a particularly concise Rust AOC, but my solutions haven't been bad at all. See last year's, with no dependencies outside the standard library: https://github.com/rpjohnst/aoc2021/tree/main/src/bin
I will certainly admit that variadic generics and default initializers would be nice in some situations. For example there have been proposals to make #[derive(Default)] support default initializers, and I have a side project I could clean up a bit with variadic impls: https://github.com/rpjohnst/dejavu/blob/main/gml/src/vm/bind.rs. But it seems to balance out overall and I don't personally experience a need to write a bunch more code, let alone just to satisfy the compiler.
Comparing raylib to bevy is like comparing a scooter to a sports car. They're not particularly comparable in functionality or design. If you want a fairer comparison, see macroquad.
I'm surprised that nobody has mentioned the D Programming Language yet. It's been around for a long time, and it's a crying shame that D hasn't reached anything like critical mass (yet?!).
Indeed you cannot. Then again, you couldn't write a library like fmtlib in C in the first place. I mean why do you complain about C++ features which enable you to write libraries you otherwise couldn't? How would you expect to implement equivalent libraries to EVE or mp-units in C alone?
Indeed you cannot. Then again, you couldn't write a library like fmtlib in C in the first place. I mean why do you complain about C++ features which enable you to write libraries you otherwise couldn't? How would you expect to implement equivalent libraries to EVE or mp-units in C alone?
My lecture linked in the README covers some of the fundamental problems in POSIX, but basically the language runtime violates zero-overhead principle (don't pay for what you don't use) in several significant ways, like initializing a heap runtime (that isn't a great way for most programs to manage memory anyways), setting up pthread thread-control-blocks that most programs don't even want to use, placing error codes into that TCB even if they are discarded. There are also opportunity costs, like code such as clone() being statically-linked assembly when it doesn't have to be (and could be optimized much better if it were otherwise).
std::vector is unfortunately kind of a mediocre container today, despite being so fundamental. The standard currently has no concept of types that are safe to memcpy ("trivially relocatable"), and a naive solution like memcpy'ing types that are trivially move constructible does not work in the general case (std::list being a motivating example). That means that reallocations in standard containers like a std::vector are sometimes 3x slower than they could be. std::vector also does not utilize allocator size feedback, leading to ridiculous workarounds in standards-conforming containers.