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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

141–150 of 396 posts

Re: Modern C [pdf]

#141

Post by loup-vaillant »

pksadiq wrote: post #129

I would recommend that anyone who hires a programmer should test his/her knowledge in C (especially in areas like code that produces undefined or unspecified results), even if the candidate is never going to code in C, ever. If he/she knows these concepts well, that means he/she have invested much time, and probably know other things well enough (or can learn them easily).

Let's not confuse low level understanding with the fine points of the C virtual machine, which drifts from whatever platform you are working on by the year.

What you really want is an understanding of how whatever code the candidate may write will map to the underlying hardware. Test for that.

Re: Modern C [pdf]

#142

Post by jeanlucas »

pksadiq wrote: post #129

I would recommend that anyone who hires a programmer should test his/her knowledge in C (especially in areas like code that produces undefined or unspecified results), even if the candidate is never going to code in C, ever. If he/she knows these concepts well, that means he/she have invested much time, and probably know other things well enough (or can learn them easily).

That's a problem if the developer never had a C influence. Depending on when you learned to code you may have never touched C.

Re: Modern C [pdf]

#143

Post by thegeomaster »

ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

I've found goto to be a good way of dealing with exceptions in low-level C. For example:

    void* foo() {
        int handle = get_some_handle();
        if (handle
I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.

Re: Modern C [pdf]

#144

Post by hellofunk »

ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

The only valid use of goto I've seen is for breaking out of nested loops; a goto statement is much easier than unwinding a bunch of breaks based on arbitrary logic or flags to notify each parent loop that a break is needed.

Re: Modern C [pdf]

#145

Post by cwbrandsma »

aleksei wrote: post #52

Another day for the HN crowd to express their distaste for C :)

Any every other language out there. It is far easier for people to identify with what they don't like than it is to identify with what they do like.

Re: Modern C [pdf]

#146

Post by cellularmitosis »

hellofunk wrote: post #144
ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

The only valid use of goto I've seen is for breaking out of nested loops; a goto statement is much easier than unwinding a bunch of breaks based on arbitrary logic or flags to notify each parent loop that a break is needed.

It's also handy for error handling / cleanup: http://eli.thegreenplace.net/2009/04/27/using-goto-for-error...

Re: Modern C [pdf]

#148

Post by pjmlp »

wiz21c wrote: post #134
pjmlp wrote: post #133

Earlier quoted context omitted.

C was not the only way of doing it. Many of us were enjoying the danger of getting low level with Think/Quick/Turbo Pascal and Modula-2.

Turbo Pascal even allowed to mix in assembler right in your source code. That was super awesome at that time. No need to write separate assembly code, no need to link ! (not to say that Turbo Pascal was the only one to do that, just fond memories...)

I once wrote a mouse driver for MS-DOS like that.

Re: Modern C [pdf]

#149

Post by loup-vaillant »

quickben wrote: post #81
adamnemecek wrote: post #74

Earlier quoted context omitted.

This C apologism is holding the industry back. Software development has changed many times over since C came out and it just isn't a good tool for tackling a lot of the issues that we have today. Just about every software project written in C has some serious bugs. I personally judge a language by how well it lets you to define abstractions. In C's case, it doesn't let you do that very well.

Your criticism lacks constructivity. What do you propose we replace C with?

Whatever doesn't have extremely tight constraints (CPU, memory, embedded…) should probably use garbage collection. Now your language can throw a nice exception (or otherwise cleanly abort the process) before any memory corruption (and subsequent vulnerabilities) can occur.

Otherwise, I'd say try something like Rust. And if Rust doesn't make the cut, maybe go write your own C-like dialect, with less undefined behaviour.

Post reply on HN