|
FlapYoJacks posted:I love junior developers. You know that's a bitwise-and, right? That's a pretty idiomatic way to check a single bit from a register that has multiple different flags in it. If you just wrote "!status" it would check if any flag was set, not just the PUSH_BUTTON_PRESSED flag.
|
![]() |
|
![]()
|
# ? Sep 23, 2023 12:01 |
|
Jabor posted:You know that's a bitwise-and, right? I should have shown the rest of the code but: - status is a bool - PUSH_BUTTON_PRESSED is define set to 0. 1 << 0 is always 1. so it’s essentially if (status & 1)
|
![]() |
|
FlapYoJacks posted:
Yeah, that's how picking out flags works. It's way easier to understand than having magic 1s, 2s, 4s, 8s, 65536s etc. in your if statements. This part's a lol though: FlapYoJacks posted:- status is a bool junior's copied some idiomatic "how do a check a flag in a register" code without understanding that they don't need it here
|
![]() |
|
Yeah, on second pass I am the terrible programmer. Luckily there’s a 9 hour time difference between us and I edited my comment on the review to ask why status is a bool. It’s me. I’m the fuckup. (I did not write the code.)
|
![]() |
|
everyones the fuckup when you're writing in c tbf
|
![]() |
|
(linus torvalds middle finger) C++ (linux torvalds grinning) Rust
|
![]() |
|
Sapozhnik posted:(linus torvalds middle finger) C++ Linus is correct.
|
![]() |
|
Sapozhnik posted:(linus torvalds middle finger) C++
|
![]() |
|
"what if C++ was even more complicated and even slower to compile and only had a single implementation and had a bunch of fanboys" i like the look of ziglang, hopefully it gets some traction. i'm much more interested in a better c than a "better" c++
|
![]() |
|
Sapozhnik posted:"what if C++ was even more complicated and even slower to compile and only had a single implementation and had a bunch of fanboys" Rust is just complicated because of the borrow checker but otherwise most of its decisions are probably what any new c/c++ replacement would do in 2023
|
![]() |
|
the design objectives are completely different. c tries to have as few abstractions as necessary to be independent of cpu architecture, under some reasonably modest (for the modern day) assumptions like a flat memory space. when you look at the statement "a = b + c" you can be reasonably sure that this will compile to something like an ADD r1, r2, r3 instruction. c++ and rust are maximalist languages that try to cram as many semantics as possible into a language before runtime type information starts to become necessary. they try to be all things to all people and involuntarily make harmful compromises as opposed to deliberately making balanced compromises. when you look at the c++ or rust statement "a = b + c" you have absolutely no idea what will happen and cannot know until you examine every single symbol that is in scope and examine their implementations. it might delete your home directory and then do a non-local return once it's done deleting it. or if b references some other data type it might launch a web server instead and then block forever. if a proc macro is involved then maybe nothing executes at all and the entire text (or okay fine, syntax tree) of the function might be turned into a map in an isometric 3D dungeon crawler.
|
![]() |
|
Sapozhnik posted:c tries to have as few abstractions as necessary to be independent of cpu architecture, under some reasonably modest (for the modern day) assumptions like a flat memory space. when you look at the statement "a = b + c" you can be reasonably sure that this will compile to something like an ADD r1, r2, r3 instruction.
|
![]() |
|
well yeah and it also errs on the side of having too few abstractions rather than too many, so it doesn't specify any particular memory ordering model and you can't really rely on sizeof(long) or obviously sizeof(void *) being anything in particular, and structure layout and alignment rules will vary as well. it's not actually architecture-independent but the architecture-specific things are mostly controllable as evidenced by the fact that cross-platform operating system kernels can be written in C with a high degree of code reuse. you wouldn't be able to do that if it was an x86_64 macro assembler. modern optimizing C compilers are a mistake imo, compiler optimizations in C should be very conservative. with a language as C you want as few codegen surprises as possible, if you didn't care about your codegen that much then you would use a language that executes on a notional virtual machine of some sort. the rampant use of UB by the specification authors shirks too much responsibility and allows exxon-mobil corporate accounting that is technically in compliance with the letter of the law to slip in to the compiler backend. you have to remember that this is a language that is mostly unchanged from its original form as conceived in the early 1970s, and for a language that old to survive and be relevant in the modern day and not have its core design decisions discredited by decades of large-scale software engineering experience is nothing short of remarkable.
|
![]() |
|
Sapozhnik posted:the design objectives are completely different. Seems like the actual issue here is with operator overloading?
|
![]() |
|
in both C and Rust you do actually need to read the library’s code to know that the function `print_money()` won’t actually delete your home directory, but in rust you can be pretty confident that it won’t randomly segfault while it’s deleting them.
|
![]() |
|
i finally got chatgpt to write me an honest to goodness malformed piece of code and it happened when i asked it to crap out a supervisord config
|
![]() |
|
it'll do dumb things and wrong things but this was the first time i saw it straight up making typos as well as butchering the interface config
|
![]() |
|
tinaun posted:in both C and Rust you do actually need to read the library’s code to know that the function `print_money()` won’t actually delete your home directory, but in rust you can be pretty confident that it won’t randomly segfault while it’s deleting them. imo it's just selection bias about the kinds of programs you'd choose to write in c in 2023. small & simple enough that they are more pleasant
|
![]() |
|
tinaun posted:in both C and Rust you do actually need to read the library’s code to know that the function `print_money()` won’t actually delete your home directory, but in rust you can be pretty confident that it won’t randomly segfault while it’s deleting them. it's more that in rust, you can be pretty confident you've called the "leopards eat my face" function correctly, no accidental null pointers, no weird dynamic casts, and a bound lifetime, but it still might randomly segfault, but it won't be your code at fault
|
![]() |
|
it's weird to talk about "design intentions" with languages like c and c++, and to some extent, rust. rust originally had garbage collection, but they eventually decided against it. at some point, typestates were considered too. rust could have easily been a wildly different language. meanwhile c's design spec was "B but with char *and* int", and C++ was "what if structs had methods *bong hit*"mystes posted:Rust is just complicated because of the borrow checker but otherwise most of its decisions are probably what any new c/c++ replacement would do in 2023 i dunno about this, some c/c++ replacements chose garbage collection because a lot of c/c++ doesn't really need to do bare metal memory management in the year of our lord 2023
|
![]() |
|
incidentally i saw an interesting post from hoare about how today's rust wasn't really what he had in mind initially https://graydon2.dreamwidth.org/307291.html i'm not really a plt person so i don't follow the finer points that he's making but maybe it's interesting to other people itt
|
![]() |
|
Sapozhnik posted:incidentally i saw an interesting post from hoare about how today's rust wasn't really what he had in mind initially i gotta admit this is a list of why i was excited for rust and also why i am disappointed in rust i guess the tldr is "graydon wanted to make a language with features but the 'we will use this to replace c++ components' argument won, so rust can't really have sufficiently nice things without losing embedding power"
|
![]() |
|
in c you pretend that the language doesn't have abstractions and is bare metal and handwave away the differences between the abstract machine and real machines in c++ you pretend that the language's abstractions are zero cost and handwave away the costs
|
![]() |
|
c the language is full of footguns, but c the abstract machine is decent at being what it aims to be
|
![]() |
|
DELETE CASCADE posted:c the language is full of footguns, but c the abstract machine is decent at being what it aims to be c's more like a language designed to construct your own byzantine footguns. disclaimer: I love c, it's my favourite programming language.
|
![]() |
|
it's kind of interesting to think about the relationship between C and modern hardware. We can all agree that modern CPUs look nothing like the abstract machine modeled by C. But yet - since so much foundational code is all in C, desktop CPUs have to be really good at acting like a PDP-11. Even when it's an absolutely terrible and incorrect model of how modern CPUs work.
|
![]() |
|
the ISA is ultimately still pretty similar. but the PDP-11 didn't have modern branch predictors, prefetchers, pipelining...
|
![]() |
|
there are parts of the C machine that are awful for optimizing compilers to work with even if you are running on a PDP-11
|
![]() |
|
Poopernickel posted:But yet - since so much foundational code is all in C, desktop CPUs have to be really good at acting like a PDP-11 and this holds back, nay, stifles the whole industry. i will not be taking questions
|
![]() |
|
Intel has a new font for programmers https://github.com/intel/intel-one-mono
|
![]() |
|
looks mostly fine but what's going on with those curly braces
|
![]() |
|
Partnering with Batman?
|
![]() |
|
quiggy posted:looks mostly fine but what's going on with those curly braces My guess is there designed to be clearly not parentheses when you're looking at code way zoomed out. We've all had array constructors where figuring that out took more effort than it should
|
![]() |
|
quiggy posted:looks mostly fine but what's going on with those curly braces
|
![]() |
|
MrMoo posted:Intel has a new font for programmers kinda liking this as an astigmatic fellow after using it for 5 minutes in a random JS project
|
![]() |
|
ikanreed posted:My guess is there designed to be clearly not parentheses when you're looking at code way zoomed out. yeah i kinda don't hate it. in c++ you sometimes get ))}}})}) and clearly distinguishing the two helps
|
![]() |
|
Next thing you know people are going to want fonts where you can tell O and 0 apart. It's a slippery slope.
|
![]() |
|
At least hypen, n dash, and m dash are completely unintelligible.
|
![]() |
|
just make it a proportional font so you can distinguish those by how long they are
|
![]() |
|
![]()
|
# ? Sep 23, 2023 12:01 |
|
every time I manage to write a line with three different types of brackets in a row I give myself a high five. never managed a line with all four. but maybe now that I’m writing in rust with its generics I’ll manage it.
|
![]() |