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

301–310 of 382 posts

Re: C’s Biggest Mistake (2009)

#301

Post by hvdijk »

jstimpfle wrote: post #290
hvdijk wrote: post #287

Earlier quoted context omitted.

It would help if you define what you mean by "object". This term has a definition in the C standard by which arrays are unquestionably objects. It is true that you cannot pass or return them by value, but that does not mean they are not objects, that means the ability to pass or return things by value is not a property of objects. About the singular vs array question: this is true but just a special case of the absen…

What GP means is "there are no array expressions in C's syntax". You can't copy them or assign them, and I'm not sure that they are part of any kind of "type system" in C (although some compilers have a notion of array type internally, which is obvious from their error messages).

That's just not true, there are array expressions, and arrays are part of the type system. I give him more credit than that. (The "you can't copy them" is technically untrue as well but that is just because of sloppy wording.)

Re: C’s Biggest Mistake (2009)

#302

Post by EdSchouten »

harry8 wrote: post #293

typedef struct fat_ptr_t { size_t size; void * start; } fat_ptr_t; extern void foo(fat_ptr_t a); if it's a good idea to use a fat pointer, why do we need new syntax to sell it? What am I missing here?

> What am I missing here?

- A concise syntax for declaring, accessing and mutating them. Dealing with lists is such a common thing in programming languages, that it's simply crazy to not have a proper syntax for them.

- Generics/templating, so that you can use concrete types instead of 'void *'. Having that prevents mistakes and also tends to make code self-documenting.

"If it's such a good idea to use a safety belt and airbags, why do we need special devices for it? Why can't I just use a piece of rope I had in a drawer and some leftover balloons from my previous birthday party?"

Re: C’s Biggest Mistake (2009)

#303

Post by jstimpfle »

Cyph0n wrote: post #107
quelsolaar wrote: post #57

Earlier quoted context omitted.

I think a better way to think about is to say that when you type: int a[10]; you allocate 10 integers and "a" is the pointer to the first one of them. Arrays are just memory, just like what you get wen calling malloc, and memory is accessed using pointers in C.

Minor nitpick: there is no allocation going on here - you’re simply reserving a fixed-size buffer on the stack (assuming the array is local to a function).

To allocate means to get or reserve something (for lack of an even better word, as a non-native). This is a perfectly valid use of allocation.

What you mean is maybe more aptly named "dynamic (memory) allocation".

Re: C’s Biggest Mistake (2009)

#304

Post by jstimpfle »

hvdijk wrote: post #301
jstimpfle wrote: post #290

Earlier quoted context omitted.

What GP means is "there are no array expressions in C's syntax". You can't copy them or assign them, and I'm not sure that they are part of any kind of "type system" in C (although some compilers have a notion of array type internally, which is obvious from their error messages).

That's just not true, there are array expressions, and arrays are part of the type system. I give him more credit than that. (The "you can't copy them" is technically untrue as well but that is just because of sloppy wording.)

You're right, I forgot about compound literals, which were introduced in C99 and which are a rarely used feature.

But I guess my statement that "C doesn't have array expressions" was true before the advent of C99. And that's also why array decay made even more sense back then. (It still makes a lot of sense today IMO).

Re: C’s Biggest Mistake (2009)

#305

Post by hvdijk »

jstimpfle wrote: post #304
hvdijk wrote: post #301

Earlier quoted context omitted.

That's just not true, there are array expressions, and arrays are part of the type system. I give him more credit than that. (The "you can't copy them" is technically untrue as well but that is just because of sloppy wording.)

You're right, I forgot about compound literals, which were introduced in C99 and which are a rarely used feature. But I guess my statement that "C doesn't have array expressions" was true before the advent of C99. And that's also why array decay made even more sense back then. (It still makes a lot of sense today IMO).

I didn't mean compound literals, I do not really see how they change things here, I meant that there are a few cases where arrays don't decay to pointers, and supporting those requires compilers to make arrays a part of the type system. Example: given "int a[3];", how else would you compute (&a+1) ?

Re: C’s Biggest Mistake (2009)

#306

Post by TeaDude »

dnautics wrote: post #187
johnisgood wrote: post #181

Earlier quoted context omitted.

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir). But I was responding to "C code is being replaced by Rust fast.".

You might like zig. It's still pre 1.0, but I feel like it really has that "get out of your way" feel of C with a ton of safety. If you write tests, you can get tested memory safety, too.

Zig has a LOT of good stuff going for it but one of my pet peeves is how arsey the linter gets about formatting. No tabs (They might begrudgingly fix that one), no multiline comment/string support (and before anyone tries to correct me on the strings front, you look at that syntax and tell me it isn't an intentional joke), you must use these specific line endings (That one was actually fixed in master recently iirc)

The syntax is also currently REALLY unstable. As in: The hello world has changed almost every major version. Hopefully that too will be squashed with 1.0

To be fair though, Zig is probably the lest egregious and most flexible of the modern "C killers". I can see it's really trying to innovate low level programming. I really like it's flexible malloc systems and support for dynamic linking at runtime. It's compile time code execution is excellent too. The fact that they're actually trying to support obscure platforms like the z80 is a good indicator that they're staying true to C's "code anywhere" mantra. That's why I'm mostly focusing on linting issues of all things.

Re: C’s Biggest Mistake (2009)

#307

Post by pjmlp »

Gibbon1 wrote: post #213
asveikau wrote: post #93

Earlier quoted context omitted.

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…

That's the way I interpreted it because it's true. A lot of the criticisms are misdirected one by people that haven't used C except being forced to use it for few assignments in school, C++ jockeys that think C is the 30 year out of date version of C that's supported by C++, and people that haven't used it at all for anything real. I also agree that what the standard committee has been doing for the last 20 years amo…

So what the improvements between C89 and C18 in regards to UB and security, for any ISO C compliant compiler?

Re: C’s Biggest Mistake (2009)

#308

Post by jstimpfle »

hvdijk wrote: post #305
jstimpfle wrote: post #304

Earlier quoted context omitted.

You're right, I forgot about compound literals, which were introduced in C99 and which are a rarely used feature. But I guess my statement that "C doesn't have array expressions" was true before the advent of C99. And that's also why array decay made even more sense back then. (It still makes a lot of sense today IMO).

I didn't mean compound literals, I do not really see how they change things here, I meant that there are a few cases where arrays don't decay to pointers, and supporting those requires compilers to make arrays a part of the type system. Example: given "int a[3];", how else would you compute (&a+1) ?

To me, the question is what is actually "the type system" and what is "the allocation system" or whatever else aspect of implementing a compiler.

So determining the type of "&a" is not an issue, it's just one case in determining the type of a C expression (look up the object "a", is it an array? The type of the expression is a pointer to the array element type).

This is not a special case, at least not more special than how to determine the type of the expression "a", or "1".

No array type needed.

Re: C’s Biggest Mistake (2009)

#309

Post by pjmlp »

IshKebab wrote: post #259
baybal2 wrote: post #147

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. I think Rust has been very quickly fading into obscurity. What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Cyclone, ATS, Checked C, Ada/SPARK.

Re: C’s Biggest Mistake (2009)

#310

Post by YeGoblynQueenne »

AlphaSite wrote: post #252
giancarlostoro wrote: post #200

Earlier quoted context omitted.

> 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.

Linux is currently investigating using Rust in drivers (The main issue being lack of compiler support for the more isoteric architectures).

Thank you for the new knowledge that "eso" is pronounced similar to "iso" in some dialects of English, I didn't know that.

However, the word "isoteric" is more correctly spelled (in non-phonetic spelling) as esoteric. The prefix "eso-" means "inside" in Greek, as in "esothermic", or "esophagus". The prefix "iso-" means "equal", as in "isomorphism", "isosceles", "isometric", etc.

Post reply on HN