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

201–210 of 978 posts

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

#201

Post by throw_m239339 »

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.

> It's a simple language with only a few concepts to learn

I mean by that logic, Assembly could be deem even simpler, yet writing OR reading programs in Assembly is absolutely not simple at all.

At the end of day, one has to write programs that solve (complicated) problems, and learning how to do that in C is difficult, thus the learning curve deemed higher when it comes to writing professional C.

I can guarantee you that writing professional Go or Java and writing correct programs in both takes way less effort than with C, for use cases that would make Go or Java viable.

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

#202

Post by DougGwyn »

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.

Try using "lint" or other code checkers.

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

#203

Post by GuB-42 »

shawnz wrote: post #85
stephencanon wrote: post #59

Earlier quoted context omitted.

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n: > A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer typ…

Wrapping around the modulus to me is an "overflow", although maybe the spec doesn't use the word that way

There is also a difference in x86 assembly, and probably others.

For unsigned operations the carry flag is used, and for signed operations, the overflow flag is used.

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

#204

Post by asveikau »

tlb wrote: post #163
beefhash wrote: post #33

Now that C2x plans to make two's complement the only sign representation, is there any reason why signed overflow has to continue being undefined behavior? On a slightly more personal note: What are some undefined behaviors that you would like to turn into defined behavior, but can't change for whatever reasons that be?

Another approach would be a standard library of arithmetic routines that signal overflow. If people used them while parsing binary inputs that would prevent a lot of security bugs. The fact that this question exists and is full of wrong answers suggests a language solution is needed: https://stackoverflow.com/questions/1815367/catch-and-comput...

Microsoft in particular has a simple approach to this with things like DWordMult().

    if (FAILED(DWordMult(a, b, &product)))
    {
       // handle error
    }

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

#205

Post by potiuper »

Any plans to add semantics for exceptional situations such as divide by zero and dereferencing a null pointer? https://blog.regehr.org/archives/232

Or incorporating features from this 14 item list? https://blog.regehr.org/archives/1180

As it appears these have failed: https://blog.regehr.org/archives/1287

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

#206

Post by throw_m239339 »

pantalaimon wrote: post #199
darepublic wrote: post #130

Earlier quoted context omitted.

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.

The trick is to just not use `malloc()` and `free()` unless absolutely necessary ;)

> The trick is to just not use `malloc()` and `free()` unless absolutely necessary ;)

The problem is that often C programmers have to deal with API and libraries they didn't write themselves to solve their problems, thus are forced to use constructors and destructors even when they don't want to.

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

#207

Post by emilfihlman »

DougGwyn wrote: post #127
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.

Though it's interesting that threads were added to the standard. Perhaps though they filled a niche that wasn't as well filled as select/poll/epoll/kqueue/etc had already since pthread api is perhaps harder.

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

#208

Post by rseacord »

a-bit-of-code wrote: post #195

Any chance that we could have an STL equivalent in C. Of course, templating and other features being absent it won't be as generic as CPP. However, having even something close to STL will help in the long run. Thanks!

There is always a chance. We would need to see a proposal based on experience with an existing implementation.

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

#209

Post by emilfihlman »

rmind wrote: post #100
emilfihlman wrote: post #50

Will you ever add / have you considered adding sane formatting options for fixed length variables in printf? Say %u32 or %s64 ? Have you considered adding access to structure members by index or by string name? Have you considered dynamic structures?

Just FYI -- there are macros for the fixed-length types, e.g.: printf("U32: %" PRIu23 ", U64: " PRId64, (uint32_t)1, (int64_t)2); Perhaps not as handy as %u32 or %s64, but it's here.

Yeah, and the issue is with those macros exactly. It makes writing code on them really damn annoying and it relies on C constant string concatenation, breaks the flow quite a lot.

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

#210

Post by Daemon404 »

rwmj wrote: post #138
Daemon404 wrote: post #58

What has been the rationale or hinderance for not adding locale-independent versions of various stdlib functions? Practically every second C codebase on earth has their own implementations of these at some point, and it remains a huge problem for e.g. writers of libraries, where you don't know how/where your library will be used.

To clarify, do you mean functions like c_isalpha (part of Gnulib) which is like isalpha but only matches 7 bit ASCII characters?

An easy (and problematic) example is decimal separators (radix characters) being parsed or written differently based on locale.
Post reply on HN