Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

191–200 of 382 posts

Re: C’s Biggest Mistake (2009)

#191

Post by dnautics »

GuB-42 wrote: post #161

I don't see a mistake here, certainly not a "biggest mistake". This is C, not C++. Keep it simple. Here, the idea is that there is no special type for "pointer+size" (what the author proposes as an array). Ok, let's add one and see the implications. - How do I get the size, the number of elements? A "sizeof" like operator? - Can I resize the array? If yes, how? If no, why? - What happens if I overflow? Undefined beha…

Ziglang is basically this plus getting rid of the preprocessor and almost all UB. It's extremely clean, quite safe, and in many ways far far simpler than C.

Here are it's answers:

- How do I get the size, the number of elements?

Builtin .len field operator. @sizeOf works too.

- Can I resize the array? If yes, how? If no, why?

No. Array lengths are comptime known; there is something called a slice which is runtime known and bounds checked in safe releases.

- What happens if I overflow? Undefined behavior?

Panic, in safe releases. UB in dangerous releases (small or fast)

- A memcpy-like would be an obvious function to implement, what happens if sizes differ?

Bounds checked at runtime for safe releases.

- What is the relationship between static arrays (ex: int a[5]) and "pointer+size" arrays? Are these completely different types? Is there an implicit cast between the two?

Yes, and yes. Arrays can implicitly be converted to slices at compile time; slicing into a slice with compile-time known index width yields an array.

- About casting, how can I go from a separate pointer and size to an array and vice versa? If it is possible at all.

There is an escape hatch function for this.

- What if I do a bit of pointer magic to access the internal representation of the array? Probably undefined behavior.

It's defined, but unsafe.

Do I haven't really worked too much in zig (it's not my daily driver) but I think it says something that all of these questions have answers to them, they are sensible, and very easy to remember.

Re: C’s Biggest Mistake (2009)

#192

Post by knaq »

brundolf wrote: post #182
knaq wrote: post #175

Earlier quoted context omitted.

Yes. If you don't really want to pass an array then don't do that. The language shouldn't get in the way when somebody wants to pass an array. Take the address, and pass a pointer, if that is what you want to do. Maybe I want the callee to be able to modify the array without affecting the caller. Maybe I'm even telling the linker to put that array in ROM, but I want a writable copy in the callee. Whatever... I have m…

I don't think you realize how intractably inefficient that would be for all but the smallest cases.

I realize exactly how inefficient it would be. If it hurts, don't do that.

I'm the kind of person who optimizes with assembly, counts cache misses, counts TLB misses, and pays attention to pipeline stalls. I definitely understand the performance implications, and I definitely wouldn't be passing arrays around all the time.

That said, I want the ability. I want the language to let me do what I want, and on rare occasions I want to pass an array. Let me pass an array.

Re: C’s Biggest Mistake (2009)

#193

Post by konjin »

munificent wrote: post #188
konjin wrote: post #156

Earlier quoted context omitted.

It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?

The relevant metric would be what fraction of hardware it's running on.

Literally all of it.

Re: C’s Biggest Mistake (2009)

#194

Post by higerordermap »

asveikau wrote: post #93
rumanator wrote: post #75

Earlier quoted context omitted.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

Maybe people are voting this down because they think it's directed at Walter Bright in particular, but I think there is actually some truth in the harsh comment. Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C. People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that u…

Maybe they thought it was yet another ruby rails webshit that recently learned rust.

Re: C’s Biggest Mistake (2009)

#195

Post by brundolf »

knaq wrote: post #192
brundolf wrote: post #182

Earlier quoted context omitted.

I don't think you realize how intractably inefficient that would be for all but the smallest cases.

I realize exactly how inefficient it would be. If it hurts, don't do that. I'm the kind of person who optimizes with assembly, counts cache misses, counts TLB misses, and pays attention to pipeline stalls. I definitely understand the performance implications, and I definitely wouldn't be passing arrays around all the time. That said, I want the ability. I want the language to let me do what I want, and on rare occasi…

Ok, but you didn't just say this should be possible, you said it should be the default best-practice. Even if it were useful in a handful of cases, this would be a terrible default way of doing things.

Re: C’s Biggest Mistake (2009)

#197

Post by dnautics »

sys_64738 wrote: post #149

I’ve been writing C code for 30 years. What I like about it is code from back then is pretty much similar to what you’d right today so there’s limited need to chase the train. Sure it has security issues but if you don things ‘right’ it’s still untouchable, imo. Most other languages are heavy and slow compared to C. A lot are not even backwardly compatible (python) or suffer from being kitchen sinks (C++). My own opi…

I think the stack for the next 30 years is going to be zig for low level code, something on the erlang vm for networks and distributed systems, and Julia for numerical computation.

It's just too hard to "do things right" in C. Even people who have been "doing things right" for decades make mistakes.

Re: C’s Biggest Mistake (2009)

#198

Post by jschwartzi »

Reelin wrote: post #84
enriquto wrote: post #31

Earlier quoted context omitted.

The real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!

Isn't much of the undefined behavior in C that people love to complain about intentionally left in the standard for the purpose of optimization? Similarly, bounds checks are necessary in insecure contexts (ie most places) but you probably don't want them slowing down (for example) an MD simulation. Edit: But to be clear, C really ought to have first class arrays. If you truly don't want bounds checks in a specific sc…

UB has nothing to do with optimization. It's about working around the differences between all the platforms that a C program might need to be compiled for. UB covers things like the layout of a signed integer(might be two's compliment, or it might not). It's about letting the platform or compiler dictate what the program does in the rare case where the program does something that might result in different behavior on different compilers and platforms.

Note that I'm using "platform" to refer to the CPU instruction set.

Re: C’s Biggest Mistake (2009)

#199

Post by noisy_boy »

konjin wrote: post #153
teej wrote: post #54

Earlier quoted context omitted.

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.

Number of blogposts about Python is a counter-argument.

Re: C’s Biggest Mistake (2009)

#200

Post by giancarlostoro »

konjin wrote: post #156
WalterBright wrote: post #59

Earlier quoted context omitted.

I suspect C has been steadily losing ground since I made it.

It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?

> By what measure would C be losing ground?

When we start seeing Rust or similar being used instead of C would be a good metric and / or major OS development.

Post reply on HN