Modern C [pdf] • Hacker News Board

Re: Modern C [pdf]

#261

Post by jackhack » Mon, Nov 28, 2016, 7:20 PM UTC

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?

I learned C from Kernihan & Richie (K&R) under supervision of experienced developers. I was really lost for a few days, the book is kind of terse. I had been developing in assembly for several years, so C felt like a really high level language. I still recall being baffled by pointers and handles, dealing with segmented memory (this was 386 days, Turbo C on the PC, MPW on the Mac for C & Pascal) It was about a month before things "clicked" and pointers made sense.

I think the follow-up C book I read after that was "Learning C". I don't recall the author's name(s) but I think it was from two brothers. Dan, something? (I'll check my bookshelf when I get home tonight and update here...).

I learned C++ initially as just 'C with Classes'. It was informal, by joining a C++ project already underway, and following the senior developer's guidelines. Instruction was informal, and under supervision of others, yet I hadn't made a complete mindshift to OO until probably six months to a year after using it.

I liked "Thinking in C++" (Bruce Eckel @ http://mindview.net/Books/TICPP/ThinkingInCPP2e.html ) quite a lot -- in fact I re-read it several times about six months apart and it seems I always pick up some new nugget of knowledge every time through. That or I forget what I don't use. Possible.

Keep in mind the newest of these is a decade old, at best. Surely not "modern" C. But after completing a basic tour of K&R C, a reader should be ready for the book at the top of this discussion. And that will transport them into this century.

hope this is helpful.

Re: Modern C [pdf]

#262

Post by Longhanks » Mon, Nov 28, 2016, 7:25 PM UTC

fryguy wrote: post #249

komali2 wrote: post #220

Earlier quoted context omitted.

This has always been my problem with websites like codeacademy, and I started my entire career by learning through that website. Take the Javascript course - a fantastic way to get introduced to the syntax of the language, and I highly recommend it for total noobies. But then you come out of it with no understanding whatsoever about what javascript is . If I asked someone who just finished the course to make an "app"…

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

Re: Modern C [pdf]

#263

Post by the_why_of_y » Mon, Nov 28, 2016, 7:31 PM UTC

SQLite wrote: post #36

SwellJoe wrote: post #9

It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to pr…

> (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable?

Variables have been called variables since the dawn of time, i.e., the lambda calculus, which doesn't even have assignment. The name derives from the idea that for every invocation of a function, a variable in its definition may be bound to a different value, hence it "varies" at runtime.

Re: Modern C [pdf]

#264

Post by jimbokun » Mon, Nov 28, 2016, 7:33 PM UTC

fryguy wrote: post #249

komali2 wrote: post #220

Earlier quoted context omitted.

This has always been my problem with websites like codeacademy, and I started my entire career by learning through that website. Take the Javascript course - a fantastic way to get introduced to the syntax of the language, and I highly recommend it for total noobies. But then you come out of it with no understanding whatsoever about what javascript is . If I asked someone who just finished the course to make an "app"…

> "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…

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

Which is why Java is a terrible language for an introductory programming class.

Re: Modern C [pdf]

#265

Post by clarry » Mon, Nov 28, 2016, 7:44 PM UTC

paulmd wrote: post #237

yekim wrote: post #225

Earlier quoted context omitted.

Hear, hear! Unfortunately, C does get a lot of hate on HN. I suspect it has to do with this site's demographics. Many (not all) of the HN clan seem to be oriented towards / mostly familiar with web based technologies. I suspect that for many who have tried, going from a web dev environment to a C oriented dev environment feels like a robust shock to the system. I'd also be willing to bet that there's an age bias at p…

It's not just that HN does a lot of webdev. It's that even in its element as a "systems language" it's virtually impossible to write 100% safe C/C++ code and guarantee that it will remain safe into the future, even for experts who are making every effort to do it right. There are just too many gotchas with "undefined behavior" and too many clever compilers out there waiting for you to make a mistake. One only needs t…

I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. Sure, you can always find people who don't know how to write a proper safety check. That doesn't mean nobody knows. You can always find people who ignore or don't know about best practices, but that doesn't mean everyone's like them. And you can find people who write goto fail; and ignore the warnings about unreachable code posted by any half-decent compiler or static analyzer, yet there are people who will pay attention to that kind of stuff. People scream UB, UB, C is evil because of UB, but goto fail is essentially a logic bug, something you could have implemented in any language. It doesn't need UB to happen.

Re: Modern C [pdf]

#266

Post by krylon » Mon, Nov 28, 2016, 7:44 PM UTC

ape4 wrote: post #213

thegeomaster wrote: post #143

Earlier quoted context omitted.

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.

This looks fine to me. I wonder if C/C++ could be improved by introducing a new keyword `bail` which is the same as `goto` but is only allowed to jump to the bottom of the function. That way, codebases can outlaw `goto` but keep `bail`.

In a previous job where I wrote C code, I had a macro named "bail" that pretty much did that: log an error message, then jump to the cleanup section of the function.

Re: Modern C [pdf]

#267

Post by CmdrSprinkles » Mon, Nov 28, 2016, 7:59 PM UTC

dang wrote: post #229

CmdrSprinkles wrote: post #76

Earlier quoted context omitted.

While I am all about C/C++ (even if I hate it), it makes sense HN is probably something like 99% web and app developers (I would argue that all are the former, but my definition may be a bit old). In those cases, you actively don't want to ever use C and anyone who does is kind of an idiot. It is the logic by which "systems project" means "script to run on a server" for a lot of people around here. And that is fine.…

> HN is probably something like 99% web and app developers Most generalizations about HN are merely projection based on sample bias, so please don't post such generalizations unless you have representative data. We're thinking about adding that sentence to the site guidelines, because spurious general claims about HN are a cliché here.

Except that this is a discussion on how news and topics are received at HN. So making a projection based on available data is actually quite reasonable and if there is a sample bias, it is a valid one. Because it doesn't matter if there are nine hundred billion hardcore VHDL folk around here. The most popular discussions tend to be tech related to web technologies and the associated tools. If the consistently popular and top discussions on HN aren't adequate to make a generalization of the general makeup of the active HN users, then I don't know what is.

And, I thought it was pretty clear with the "probably something like" and "99%" that it was a number being pulled out of my arse for the sake of discussion.

That being said, actual data on the skillsets and interests of the more active members would be a very interesting bit of data. But it is also really hard to measure as lurkers don't contribute to discussion but will gladly vote in a poll.

Re: Modern C [pdf]

#268

Post by sidlls » Mon, Nov 28, 2016, 8:01 PM UTC

junke wrote: post #260

sidlls wrote: post #239

Earlier quoted context omitted.

Your first statement is pretty false, even in Rust (for example). Unless you mean something else by "buffer overflow" than I'm accustomed to.

You are right, "do not happen" sounds too much like "will never happen". See also Wikipedia's entry about that example[0]. My point is that if the programmer can't prove accesses are always within appropriate bounds, there should be a runtime check. That is simple. This is not "slow" (and even in the case it you need it fast and are ok to randomly crash, avoiding checks should be explicit). And some languages do it b…

Well, yes, I agree in general bounds should be checked at runtime when it isn't possible to statically verify access at compile time.

I'm not sure how default access in C or C++ isn't explicitly avoiding checks. By definition "a[b]" is an unchecked dereference. It doesn't get more explicit than "by definition." Of course if by "explicit" you mean "syntax exists that demarcates unchecked access" then C and C++ will never satisfy. I'd argue that's a contrived and artificially narrow use of "explicit" meant, er, explicitly to exclude C and C++ from being acceptable by definition and therefore not terribly fair.

Re: Modern C [pdf]

#269

Post by digler999 » Mon, Nov 28, 2016, 8:09 PM UTC

grabcocque wrote: post #57

buserror wrote: post #56

Earlier quoted context omitted.

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

If the handle of the hammer you're holding was a chainsaw that randomly turns on and off. And also sometimes explodes killing your entire family and pet dog. Don't blame the explodey-chainsaw-hammer, it's just a tool . Okay an idiotically dangerous too that nobody in their right mind should use, but still just a tool.

> sometimes explodes

thought you were talking about java bloatware for a second. Oh your OS doesn't have 1.2gb for HelloWorld.class? Enjoy your OutOfMemoryException!

Re: Modern C [pdf]

#270

Post by sqeaky » Mon, Nov 28, 2016, 8:11 PM UTC

clarry wrote: post #265

paulmd wrote: post #237

Earlier quoted context omitted.

It's not just that HN does a lot of webdev. It's that even in its element as a "systems language" it's virtually impossible to write 100% safe C/C++ code and guarantee that it will remain safe into the future, even for experts who are making every effort to do it right. There are just too many gotchas with "undefined behavior" and too many clever compilers out there waiting for you to make a mistake. One only needs t…

I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. Sure, you can always find people who don't know how to write a proper safety check. That doesn't mean nobody knows. You can always find people who ignore or don't know about best practices, but that doesn't mean everyone's like them. And you can find people who write goto fail; and ignore the warnings about unreachable cod…

I think that you have the formulation backwards. You claim that people can just write better, and should attain perfection.

> I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code.

I think most people come at the other way. Most people are aware that they are fallible and wants tools to help with that. Most people strive for perfection and none will ever actually attain it.

> I don't think anyone can demonstrate that it is virtually impossible to discover errors safely in C code.

There is a huge difference simply moving from C to C++ with exceptions. The type system in C++ can detect several classes of errors at compile time and prevent then grom going into the results.

Then for runtime problems if an underlying functions throws, it cannot simply be ignored. Any programmer can miss a single statement, or worse refactor a function with a void return to one that returns and error code (which then results in every caller ignoring the return value). However, it takes a special kind of malice to use something like carelessly catch(...) in C++ to disregard exceptions so that runtime errors are avoided. C++ with exceptions has more sane defaults because it fails fast and the failing itself doesn't need tests until it starts doing something meaningful.

Now imagine the advances in error detection moving to languages that catch additional classes of errors.