61–70 of 130 posts
Earlier quoted context omitted.
Zig and Rust also support array slices. But they can’t be null, because that’s - as the article says - a mistake. https://ziglang.org/documentation/master/#Slices https://doc.rust-lang.org/book/ch04-03-slices.html
D slices can be null, but they're not a mistake, as the runtime will not let you read/write a 0 length array.
Earlier quoted context omitted.
At the cost of basically all performance or incredible compiler complexity. A better solution: Implement a different language with a better type system instead. Or pick one of the hundreds that already exist and can represent the concept of a tagged union without having to implement it manually.
I am absolutely in favor of languages that exclude nulls from their type systems, bur your first point is a very simplictic take. Null pointer checks are very, very cheap, no additional memory fetch since the pointer value is needed either way, easy to predict the slow path and if we are talking about languages that can deoptimize, then it is literally free (checked by hardware either way) -> a null value will cause…
Yes, the NULL check (effectively, in most cases) happens via hardware either way, but it's a lot cheaper to have the MMU raise a page fault because you tried to read/write an unmapped page than it is to litter every pointer access (or at least every initial non-volatile pointer access) with a conditional jump.
I have no problem with someone adding compiler flags to enable slightly optimised NULL checking across every pointer access but I guarantee nobody will enable it for any code written in C for a reason as it will kill performance. Consider the instruction cache impact. You're also way over-estimating the branch predictor. Yes in hot code you will not see a major impact, but this is not something the kind of people who write high performance C really bet on anyway. And don't bring up __builtin_expect and friends, they don't do anything on AMD64, one of the most popular architectures in the world.
Now for software which is written in C for no good reason, there's a perfectly sensible target for this feature.
If null references are a mistake, isn't initializing an array index variable to -1 a mistake too?
If null references are a mistake, isn't initializing an array index variable to -1 a mistake too?
Yes. Make illegal states unrepresentable.
Earlier quoted context omitted.
This is what C/C++ haters, anti x86/amd64 snobs, and Rust elitists always forget: what works, works. Sure, it could be a local maximum, hopefully there will be better, but who knows? To quote Sean Connery in The Rock: Losers always whine about their best. Winners go home and fuck the prom queen! https://m.youtube.com/watch?v=gXDSxgDUv-c
Nailed it with this quote, especially because it scales to all levels of product development. Literally the only thing that matters (in the context of business success, of course) is if it works enough to keep going up and the the right. No one cares about your code.
Right, because that's a one-bit truth value, not a scalar. The slope doesn't matter, it just has to be positive. Everything is so simple!
There's no such thing as high margins, or success in degrees.
Is there something adding friction to the process of making software/food/cars? Well, is it adding enough friction to make our profits go negative? No? Then literally no one cares.
Earlier quoted context omitted.
Zig and Rust also support array slices. But they can’t be null, because that’s - as the article says - a mistake. https://ziglang.org/documentation/master/#Slices https://doc.rust-lang.org/book/ch04-03-slices.html
D slices can be null, but they're not a mistake, as the runtime will not let you read/write a 0 length array.
"var x []int; fmt.Printf(`%p %d`, x, len(x))" outputs "0x0 0"
Indexing "x[0]" results in: "panic: runtime error: index out of range [0] with length 0"
They can also be appended to and then produce a valid slice.
Earlier quoted context omitted.
Which would all be a rounding area if C gets to take credit for everything produced using it.
This is what C/C++ haters, anti x86/amd64 snobs, and Rust elitists always forget: what works, works. Sure, it could be a local maximum, hopefully there will be better, but who knows? To quote Sean Connery in The Rock: Losers always whine about their best. Winners go home and fuck the prom queen! https://m.youtube.com/watch?v=gXDSxgDUv-c
Earlier quoted context omitted.
This is what C/C++ haters, anti x86/amd64 snobs, and Rust elitists always forget: what works, works. Sure, it could be a local maximum, hopefully there will be better, but who knows? To quote Sean Connery in The Rock: Losers always whine about their best. Winners go home and fuck the prom queen! https://m.youtube.com/watch?v=gXDSxgDUv-c
Nailed it with this quote, especially because it scales to all levels of product development. Literally the only thing that matters (in the context of business success, of course) is if it works enough to keep going up and the the right. No one cares about your code.
Guess where I'm taking that prom queen analogy
Nah. The billion dollar mistake is actually C arrays decaying to pointers, enabling buffer overflows, the #1 cause of bugs and malware injection in shipped C programs. https://www.digitalmars.com/articles/C-biggest-mistake.html It's simple to fix this in C, too.
That's the same kind of trade off as with zero as end of string marker.
On the other side: the platform might not have received any following without saving a few bytes here and there, computer memory was a scarce resource at the time.
Earlier quoted context omitted.
just require the programmer to check errno after every function call? /s
omg. I forgot about that. the one thing even worse than overloading the return domain.
sqlite C libraries apparently still do this. The person who wrote the code was both not very good and had no idea that an error was even occuring.