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

191–200 of 396 posts

Re: Modern C [pdf]

#191

Post by wolfspider »

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

Yes I totally agree with this and think that it's funny when people go off on the danger or C due to the fact I learned it along with many other kids between the ages of 8 and 12. At Oglethorpe University they ran a coding camp for children like me interested in learning C, QBasic, and ASM. At the behest of a fan letter I wrote to LucasArts as soon as I saw a C instructional class for younger people I had access to I signed right up. Being in Florida that was the closest me and my family could find and within our budget. I remember there was one kid in the ASM class who made a TSR for another more obnoxious student that re-wrote his hard drive until it physically broke. It was quite the statement but some of us apparently didn't consider these design features dangerous rather we considered them powerful. As far as writing good C code is concerned if a bunch of pre-teens could do it then I'm sure its possible for anyone given enough practice.

Re: Modern C [pdf]

#192

Post by colanderman »

yoha wrote: post #187
colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->".

The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.

Re: Modern C [pdf]

#193

Post by colanderman »

imron wrote: post #185
colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)

I agree. For this reason I wish the author would promote (no pun intended) the use of signed arithmetic.

Re: Modern C [pdf]

#195

Post by colanderman »

cygx wrote: post #188
colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

I would not let that line pass code review. Obviously. However, it is an appropriate example if your goal is to teach the intricacies of the C language. You're right that if you provide such an example this early, it could perhaps use some additional commentary. Not only is that confusingly cutesy, but largeA[i] is a double. That was the point of the exercise: !! is an idiom to convert to boolean (which happen to be…

I agree they are great examples to test understanding, but if they're going to be present in the first chapter of a pedagogical book, they need a disclaimer. People copy things.

Re: Modern C [pdf]

#196

Post by snerbles »

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

C also allows for inline assembly.

Re: Modern C [pdf]

#197

Post by vram22 »

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

Interesting. Though I used Turbo Pascal quite a lot earlier, I either don't remember that feature (being able to mix in assembly) or may have known of it then but forgotten it later. Getting a vague recollection - was it something like a function call of sorts (syntax-wise)? Start with a $something, then open parens, then some assembly statements, then close parens)?

If that was the way it was done in TP, the BBC micro (which was mentioned quite a bit in the recent HN thread about BASICs on personal computers of earlier years), also had a similar feature. I did use that one a bit. You had to open a square bracket in the middle of your BASIC program (though probably not in the middle of a BASIC statement), write your assembly code (6502 instruction set), and then close the square bracket, IIRC.

D (language) these days also has the ability to mix in assembly, though I haven't tried it yet.

Edited for typos and wording.

Re: Modern C [pdf]

#198

Post by progman »

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

As for me, I like C because I consider it a "high level assembler", as a backend for modern programming languages like Nim which profit from the C compiler's strong code optimizations. If there is any new hardware platform, there usually is a C compiler, too. This makes porting source code really easy.

Re: Modern C [pdf]

#199

Post by yoha »

colanderman wrote: post #192
yoha wrote: post #187

Earlier quoted context omitted.

Decrementing loops is the one place where I have indulged in some trickery. I do: for (size_t i = 9; i --> 0; ) This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do: for (int i = 9; i >= 0; i -= 1)

Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.

This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t).

Obviously, I just follow the convention when contributing to an existing project.

Re: Modern C [pdf]

#200

Post by pselbert »

jackhack wrote: post #179

I wish I could like this book, but after reviewing the first chapter I can only imagine the confusion of students. I support very much the idea of breaking the book into levels, but it attempts to cover far too much, far too quickly and I don't believe this book would be useful for those who are not already familiar with the language. I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in…

Your experience sounds spot on to me.

No matter what you are teaching, whether it is fundamental like reading, physical like a sport, or technical like programming, it is critical to teach ONE THING at a time. Teaching multiple concepts at once muddles the exercise and slows down learning. Breaking large concepts into discrete blocks lets the student focus and then build on that concept as they continue.

That's certainly how I work, and how I've heard experienced teachers explain it.

Post reply on HN