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

331–340 of 396 posts

Re: Modern C [pdf]

#331

Post by kLeeIsDead »

Longhanks wrote: post #262
fryguy wrote: post #249

Earlier quoted context omitted.

> "what does `public static void main` mean?" The problem with this question is that there is a ton of stuff you need to understand before you can really answer that question fully. To know what public means, you need to understand classes, and visibility rules for classes. To understand static fully, you kind of need to know how c++ works, since it's equivalent to a bare function in a namespace. Void is the type of…

Then why start teaching programming with Java in the first place when understanding those concepts involves an at least mediocre understanding of object orientation? There are many more languages that implement a "Hello, world!" with one line of code. If explaining "public static void main" is too hard, maybe one is using the wrong tool.

Because, College Board.

I'm so glad I learned Lua before taking APCS, otherwise that class probably would have set me back 6 years.

Re: Modern C [pdf]

#332

Post by kLeeIsDead »

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)

That first example reads like a horrible pun.

Re: Modern C [pdf]

#333

Post by Retra »

ticviking wrote: post #280
khedoros1 wrote: post #276

Earlier quoted context omitted.

It was the first object-oriented language that I learned, and some of my classmates' first language. It wasn't too bad to be told "Just type it for now; we'll get into object orientation next week and explain it then." From my own experience, I don't think it's a big issue if it's introduced correctly.

I suspect you are far more willing to learn by rote than some other students. For a particular kind of curious student, "just do it because you have to" is a very fast way to them checking out and doing nothing at all.

That sounds more like a problem with incoming student's expectations than with the teaching method. Almost every interesting (i.e., sufficiently complex) subject isn't arranged in a pedagogical hierarchy. You can't explain history from the first day, because you'd have to explain where that knowledge came from. You can't explain math without pushing things for later because students are not prepared for generality on day 1. You can't explain human biology by describing various cells. Etc..

If a student is going to 'check out' because they didn't get a question answered, then they're probably just going to fail. See your teacher after class, ask a friend, look it up online... If are a 'curious student' doesn't see these very obvious methods of satisfying their curiosity, then they're probably not worth a teacher's efforts.

Re: Modern C [pdf]

#334

Post by mioelnir »

khedoros1 wrote: post #288
ticviking wrote: post #280

Earlier quoted context omitted.

I suspect you are far more willing to learn by rote than some other students. For a particular kind of curious student, "just do it because you have to" is a very fast way to them checking out and doing nothing at all.

I held onto the promise of a forthcoming explanation (and read ahead in the book, anyhow). Honestly, someone who can't deal with a little ambiguity when starting out on a new technology isn't going to last long in the field anyhow, especially with the amount of self-learning that you end up doing.

Agreed, for a number of students the promise to explain it later will suffice. Others - when given magic boilerplate that does strange, intended things - will recognize it for the black magic it is and will want to wield it as well.

They will dissect, examine and research it on their own and their learning will be much deeper.

Re: Modern C [pdf]

#335

Post by Retra »

ArkyBeagle wrote: post #317
junke wrote: post #216

Earlier quoted context omitted.

Vulnerabilities like buffer overflow do not happen in languages with a string type. Humans are responsible if something bad happens, but without a safety net, the outcome is worse.

C has a perfectly useable (null-terminated) string type, and there is no good reason to ever have a buffer overrun in C. I understand that this is... obscure for some reason and I'm not saying it never happens, but let's be realistic....

C has a char* type, which we call a string, but it is also the type of a pointer to a single char, which is not a string at all, and also something perfectly usable. "Ends with nul" is barely a part of C, it's more like a programmer's agreement. The language doesn't enforce it, require it, or check it. All it does is insert nul characters in literals, which is hardly enough to make a string type.

Thus if you have a to_upper(char*) function, you don't know what it takes or does without looking it up. Does it uppercase a single character or a whole string? How do you even tell what you were passed without potentially reading past the end of a buffer?

If I happen to have a pointer-to-char and pass it to a to_upper function that operates on strings, it will just write on invalid memory, because C can't distinguish between the two.

Re: Modern C [pdf]

#336

Post by sidlls »

pcwalton wrote: post #171
buserror wrote: post #105

Earlier quoted context omitted.

"Just about every software project written has some serious bugs" There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C. I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself.…

> Seriously, vulnerabilities and bugs are found everywhere not just in C. The black-and-white security fallacy again! The simple fact (and this is a fact, not an opinion) is that the most severe security problems—remote code execution, in particular—are found way way way more in programs written in C and C++ than in other languages.

Per unit of code or as an absolute value? That's significant, but not even the whole picture. It's trivial to have a low (absolute and per-unit) number if the total number of units is low, for example. So by itself your fact is almost useless.

Re: Modern C [pdf]

#337

Post by sea6ear »

kruhft wrote: post #233

The best book I had for learning more about C was titled 'Writing Bug Free Code For Windows' from the late '90s early 2000's. It contained a complete object oriented system using simple header tricks and data hiding plus covered all sorts of pre-processor tricks that aren't evident until you really dig into what C can really do. I'm sure it's impossible to find now, but recommended.

Is this the book you are talking about [1]? If so, it looks like the author has put it online for free.

[1] https://www.duckware.com/bugfreec/index.html

Re: Modern C [pdf]

#338

Post by emptybits »

Watabou wrote: post #308
yekim wrote: post #230

Earlier quoted context omitted.

Yes - a thousand times yes! The goto has gotten a bad rap over the years because of Dijkstra's paper. And that paper has unduly influenced a lot of incorrect thinking. There are valid use cases for goto, and this is certainly one of them. I use it all the time like the example above. Particularly because it makes my life so much easier when developing and debugging embedded C code across various tool chains, some of…

Just curious, not a C developer by any means, but why wouldn't you use a function here instead of a goto? I'm confused how goto would reduce error/improve readability in that example. Again, not criticizing, genuinely want to know.

Simply: a goto never returns while a function call returns to where it was called from.

So specifically in the example above, if you called failure-handling functions instead of using goto's then when the function returned you would continue execution on the next line after the function call. In the example above, that's clearly not what you want.

Now you could add some else's after the function calls to prevent execution from continuing. i.e. to get to the appropriate step in the free_* sequence at the bottom, but that starts to look messy. So I have to admit (not being a goto-lover), the above example reads very nicely.

It conforms to the "gotos might be okay if they only jump forward" rule of thumb I've heard.

Re: Modern C [pdf]

#339

Post by hackermailman »

xenihn wrote: post #232
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…

Do you have any recommendations for books?

CS:App book, from 15-213 at CMU goes well with K&R to teach unsigned/TMIN/Float/pointers at the asm level, gdb, Valgrind to check for mem leaks, compilation gotchas and more. http://csapp.cs.cmu.edu/

Re: Modern C [pdf]

#340

Post by Retra »

digler999 wrote: post #257
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.

It's been brought up that there are a few handy uses for goto. I think the reason it's so heavily preached against is because of its name. For someone just starting out, the word "goto" might sound like a handy tool that could be useful for all sorts of things. But instead of a measured response to make it the last tool you reach for, it's been made into a pariah.

It's only more useful than structured code in a few niche situations, and even then, it doesn't usually provide massive benefits. It's a language construct that doesn't carry its weight.
Post reply on HN