Panzerschrek
Joined 113 karma
- PanzerschrekBy using a better language you have no errors typical for C which usually require debugging. Logical errors may still happen, but they are easy to identify without even running a debugger.
- 50 years of widespread C usage has shown that just trying writing without errors using C doesn't work. But surprisingly some people still believe it's possible.
- I am surprised that a language with nothing than a couple of promises gets so much attention. Why exactly?
- How does it achieve memory safety?
- If debugging is 2 times harder than writing code we have at least two choices. One suggests to write simpler code. But another one means not debugging code at all, which may be achieved by using a programming language way better than C, which allows fixing (almost) all bugs in compilation time.
- The utility of such container seems for me to be questionable. It's likely an error to modify vector while iterators to its elements exist. I see no legit reason to modify a vector with preservation of iterators.
- Is it memory safe? Can I write code with use-after-free errors? Can I read/write memory outside bounds?
- Can it run Doom?
- I don't understand the part about key removal. Is it correct to shift values to the left? Can't it break lookups for keys inserted into their natural positions?
- I was surprised when I realized, that a game from year 2004 still had a software renderer. But I thought it was just old leftover from the first Unreal game.
- In my programming language (see my latest submission) I wanted to do so. But then I realized, that in rare cases global mutable variables (including thread-local ones) are necessary. So, I added them, but their usage requires using an unsafe block.
- I can: https://godbolt.org/z/Kc8cTddd5 Compilers still struggle to optimize non-trivial recursive functions, where obvious non-recursive approach is possible.
- It's a good decision to add at least some checks into C++ standard library. But no runtime check can find a bug in code like this:
A better language is needed in order to prevent such bugs, where such compile-time correctness checks are possible. Some static analyzers are able to detect it in C++, but only in some cases.std::vector<int> v; v.push_back(123); auto& n= v.front(); v.push_back(456); auto n_doubled= n * 2; - How does your compiler manages to perform lifetime check? What if I save a pointer allocated from an arena somewhere, so it outlives it? What if I forgot to free memory via defer?
What about spatial memory safety? Can I read/write outside allowed memory by misusing pointer arithmetic?
What about concurrent access? What if a pointer to some piece of memory is invalidated by some other code?
- How does it achieve memory safety?
Does it have destructors and RAII?
Does it have type and function templates?
- It seems to be typical - some calculations break while switching from x87 to SSE. The same happened with TF2 too - it's ammo calculation code worked slightly differently on GNU/Linux build of the game, because it was built with SSE instructions (Windows version still used x87).
- How real is this specific case of supply chain attack? Are there any known cases of this specific attack?
- After reading this article I have yet another idea how to handle errors. A caller should provide two return addresses for a calle - one for normal return and another one for error return. Doing so isn't particularly costly - it requires pushing an error-handler block address before the call instruction and popping it after. It should be easier compared to unwinding, since no side-tables are necessary and thus going the error path shouldn't be substantially costly compared to the happy path.
- The problem is that Gnome/KDE/XFCE and others aren't strictly-speaking Linux-specific, but support other Unix-like operating systems. This makes possible standardization much more comlpex.
- Typical xkcd 927 case.