Question for pros: I'm a Python dev who recently started diving into C++, hoping to build plugins for DCCs. However, every time I read these threads, I feel as if I'm on the completely wrong path. Positive views like the OP's are rare.
While I understand that not everyone gets to work on a John Carmack level codebase, is working on a C++ project really as challenging and unrewarding as it seems? Is the productivity that low, and do every step feel so difficult that they eventually drive developers away?
Most countries should study the Brazilian system called Pix. It's faster than Interac, controlled by the central bank and very accessible to its population.
https://www.bcb.gov.br/en/financialstability/pix_en
I know nothing about Zig, but this is pretty interesting and looks well designed. Linus was recently very mad when someone suggested a new semantics for overflow:
——
I'm still entirely unconvinced.
The thing is, wrap-around is not only well-defined, it's common, and
EXPECTED.
> The thing is, wrap-around is not only well-defined, it's common, and EXPECTED.
No, it's really not. Do this experiment: for the next ten thousand lines of code you right, every time you do an integer arithmetic operation, ask yourself if the code would be correct if it wrapped around. I would be shocked if the answer was "yes" in as much as 1% of the time.
(The most recent arithmetic expression I wrote was summing up statistics counters. Wraparound is most definitely not correct in that scenario! Actually, I suspect saturation behavior would be more often correct than wraparound behavior.)
This is a case where I think Linus is 100% wrong. Integer overflow is frequently a problem, and demanding the compiler only check for it in cases where it's wrong amounts to demanding the compiler read the programmer's mind (which goes about as well as you'd expect). Taint tracking is also not a viable solution, as anyone who has implemented taint tracking for overflow checks is well aware.
For the kernel, which deals with a lot of device drivers, ring buffers, and hashes, wraparound is often what you want. The same is likely to be true for things like microcontroller firmware and such.
In data analysis or monte carlo simulations, it's very rarely what you want, indeed.
There are definitely cases where wraparound behavior is correct. There are also cases hard errors on overflow isn't desirable (say, statistics counters), but it's still hard to call wraparound the correct behavior (e.g., saturation would probably work better for statistics than wraparound). There are also cases where you could probably prove that overflow can't happen. But if you made the default behavior a squawk that wraparound occurred, and instead made developers annotate all the cases where that was desirable to silence the squawk, even in the entire Linux kernel, I'd suspect you'd end up with fewer than 1000 places.
This is sort of the point of the exercise--wraparound behavior is often what you want when you think about overflow, but you actually spend so much of your time not thinking about it that you miss how frequently wraparound behavior isn't what you wanted.
I think wraparound generally is better for statistics counters like the ones in the linked code, since often you want to check the number of packets/errors per some time interval, which you can do with overflow (as long as the time interval isn't so long that you overflow within a period) but not with saturation.
I think it's critical that we do annotate it as a special multiply.
If wraparound is ok for that particular multiplication, tell the compiler that. As a sibling comment says, this is seldom the case, but it does happen, in particular, expecting byte addition or multiplication to wrap around can be useful.
The actual expectation of the vast majority of arithmetic in a computer program is that the result will be correct in the ordinary schoolyard sense. While developing that program, it should absolutely panic if that isn't the case. "Well defined" doesn't mean correct.
I don't understand your objection to spelling that `val *% GOLDEN_RATIO_32` is. When someone sees that (especially you, later, coming back to your own code) it clearly indicates that wrapping is expected, or at least allowed. That's good.
Unsigned integer overflow is not undefined in C or C++. You can rely on how it works.
Signed integer overflow, on the other hand, is undefined. The compiler is allowd to assume it never happens and can re-arrange or eliminate code as it sees fit under that assumption.
How many lines will this code print?
for (int i = INT_MAX-1; i < 0; ++i) printf("I'm in danger!\n");
Because it creates more problems than it solves. A movie set is expensive and moves fast – and keying is not as big of a problem as they made it out to be.
For example, Niko doesn't seem to be aware of the IBK keyer (based on his comments in the VFX subreddit), which is the keyer used on almost every shot in high-budget movies. While it's not a single-click solution, it's the main tool to tackle thousands of shots with defocused edges, motion blur, and semitransparency every year.
Niko deserves credit for bringing Paul's incredible experiment, but Corridor is at its core a group of entertainers, and most of them have never had experience in a large production/VFX environment. Take everything they present with a grain of salt.
I'm seeing shots that would be incredibly expensive for some productions - even if we ignore the ones requiring visual effects work. Some of them would need small crews, permits, rentals of expensive equipment, casting, and travel. It's impressive and concerning at the same time.
Is there any i3wm alternative that works with Wayland on Nvidia hardware (proprietary drivers)? I tried Sway and Hyprland last month but found neither ready for daily use.
The terminal window from VSCode still gives you all of that, with some extra ergonomics from the GUI. No need to remember ctrl b + % to split a Tmux window, scrolling and find just works, no need to install plugins to save sessions.
While I understand that not everyone gets to work on a John Carmack level codebase, is working on a C++ project really as challenging and unrewarding as it seems? Is the productivity that low, and do every step feel so difficult that they eventually drive developers away?
reply