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

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

Post reply on HN
Print view View original

121–130 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#121

Post by orsenthil »

pantalaimon wrote: post #87
orsenthil wrote: post #68

Why is still the learning curve for C so high? * Why can't the learning curve be solved using tools? * Why don't we actively promote more higher level languages which are implemented in C (by fewer people)?

Do you find the learning curve for C to be high? I find it quite the opposite. It's a simple language with only a few concepts to learn, once you got those, that's it. There might be some preprocessor tricks you'll pick up later, but the base language and library is pretty comprehensive IMHO.

C is indeed a very small language. But the expressive power of C for real-world problems brings a huge learning curve in terms of organization, tracking, and understanding.

Re: Tell HN: C Experts Panel – Ask us anything about C

#122

Post by steveklabnik »

jfkebwjsbx wrote: post #86
DougGwyn wrote: post #62

Earlier quoted context omitted.

In BRL's MUVES project, we used a 2-character prefix indicating category. E.g., all the external identifiers for our fancy memory allocator began with "Mm", where Mm.h documented the interface for the Mm package only. To minimize the external identifiers, one could make just the name of a container structure the sole entry access handle, with structure members pointing to the functions. Then use it like: #include if…

Tip: you can use four leading spaces to write code. Like this

You only need two!

  like this

Re: Tell HN: C Experts Panel – Ask us anything about C

#123

Post by rwmj »

Not a question, a request: Please make __attribute__((cleanup)) or the equivalent feature part of the next C standard.

It's used by a lot of current software in Linux, notably systemd and glib2. It solves a major headache with C error handling elegantly. Most compilers already support it internally (since it's required by C++). It has predictable effects, and no impact on performance when not used. It cannot be implemented without help from the compiler.

Re: Tell HN: C Experts Panel – Ask us anything about C

#125

Post by pcr910303 »

nicoburns wrote: post #81

Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example: - Locking down some categories of "undefined behaviour" to be "implementation defined" instead. - Proper ar…

Or... deprecating unsafe or not-well-designed (but this is a bit subjective) ideas. Like... deprecating locales. (For why locales aren't well-designed ideas: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...)

Re: Tell HN: C Experts Panel – Ask us anything about C

#126

Post by wcarey »

I'm teaching C to high schoolers as their first language, which is quite the adventure. Do you have any good advice or resources on how to introduce the way C treats the function stack and heap allocated memory? Most of my students struggle (naturally) with making sense of function scoped identifiers and pass-by-value semantics.

Re: Tell HN: C Experts Panel – Ask us anything about C

#127

Post by DougGwyn »

emilfihlman wrote: post #104

Have you considered adding multiplexing capability to the standard? It would be great to have a directly portable one.

We would need a specific proposal and assurance that nearly all computers can efficiently provide that service. It is more likely in the POSIX standard.

Re: Tell HN: C Experts Panel – Ask us anything about C

#128

Post by AaronBallman »

AvImd wrote: post #95

Is there a possibility there will be introduced a new rule saying "if the compiler detects an UB it should abort the compilation instead of breaking the code in the most incomprehensible way possible"? Right now it's just scary to start a new project in C. It would be really great if there was more emphasis on correctness of the produced code instead of the insane optimizations.

It would be wonderful (IMO) if we could get to that point, but that would leave implementations with too great of a burden because many forms of UB can only be caught at runtime (without a considerable number of false positives). Generally, the C committee makes things a "constraint violation" (aka, we would like implementations to err) whenever something can be caught at compile time, and we leave the undefined behavior hammer for scenarios where there is not a reasonable alternative.

Thankfully, there are a lot of tools to help developers catch UB these days (UBSan, static analyzers, valgrind, etc). I would recommend using those tools whenever starting a new project in C (or C++, for that matter).

Re: Tell HN: C Experts Panel – Ask us anything about C

#130

Post by darepublic »

pantalaimon wrote: post #87
orsenthil wrote: post #68

Why is still the learning curve for C so high? * Why can't the learning curve be solved using tools? * Why don't we actively promote more higher level languages which are implemented in C (by fewer people)?

Do you find the learning curve for C to be high? I find it quite the opposite. It's a simple language with only a few concepts to learn, once you got those, that's it. There might be some preprocessor tricks you'll pick up later, but the base language and library is pretty comprehensive IMHO.

Coming from python/js I found it to be high. Mostly because of the memory management/ making sure I call free correctly etc. In many cases where I would plow ahead in programming, with C I had to stop and would feel dread. A lifesaver for me was using C/C++ Repl environments where I could quickly prototype or sanity check things I was doing.
Post reply on HN