4 ms·
What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?
by gnuvince 5y ago
What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?
- ashconnor 5y agoC99 I would imagine: https://en.wikipedia.org/wiki/C99 https://en.wikipedia.org/wiki/C99
- unwind 5y agoThe current standard is C17, of course: https://en.m.wikipedia.org/wiki/C17_(C_standard_revision) https://en.m.wikipedia.org/wiki/C17_(C_standard_revision).
- mumblemumble 5y agoAccording to the introduction of the book, C17. Which is mostly just bugfixes on C11. But, compared to c99, you get nice things like generic expressions, better unicode, and (standard) multithreading.
- wott 5y ago> But, compared to c99, you get nice things like generic expressions I'd have a hard time calling the way they designed _Generic "a nice thing" :-)
- beej71 5y agoI'm chuckling to myself at "there are not many new language features" because that's what I thought. There's fair amount added to the core since C89, actually... And if you include the library changes, game over! I had no idea how much had been added. More challenging is to find what's been subtracted. This no longer defaults to int: static i; And gets() is toast. Anyone know any others?
- JoeAltmaier 5y agoArray initializers! Lots of changes there. Oh, things subtracted? Wasn't there a change in typedef vs type tags?
- pjmlp 5y agoVLAs, made optional in C11, so compilers that jumped from C89 to C11, like on embedded space, or MSVC, never bothered with supporting them.
- thamer 5y agoApart from the new features added in C11 or C17 that others have mentioned, both Beej's Guide and Modern C also cover threads and string encoding (neither of these topics are covered in K&R 2nd edition, as far as I remember). Beej's Guide also has a section on internationalization and one about date/time handling. But yes, the code is also quite different than in K&R which is relatively terse. See for example this comment in K&R about strcpy on print page 105 (page 119 of the PDF)[1], where after showing two versions of strcpy that are pretty readable and easy to follow, the book says: > In practice, strcpy would not be written as we showed it above. Experienced C programmers would prefer void strcpy(char *s, char *t) { while ((*s++ = *t++) != '\0') ; } Followed by a paragraph saying the condition could be simplified, and that > the function would likely be written as void strcpy(char *s, char *t) { while (*s++ = *t++) ; } Make of that what you will :-) [1] https://kremlin.cc/k&r.pdf#page=119 https://kremlin.cc/k&r.pdf#page=119
- derefr 5y agoI know that while (*s++ = *t++); is the type of thing seemingly designed to reach through history to make a modern programmer spit out their tea — but I also can’t help but feel that it’s a very direct “C machine” representation of the semantics of a processor string instruction, ala x86’s REPNZ MOVSB.
- pjmlp 5y agoWhile experienced C programmers that care about security wouldn't even touch strcpy(). All those code samples will crash and burn if s and t point to the wrong locations, t happens to point to a string without a null terminator, or s points to a buffer not big enough to handle the string pointed by t.
- tom_mellior 5y ago> All those code samples will crash and burn if s and t point to the wrong locations This is true for all uses of pointers in C. The only validation you can do is whether a pointer is null. Apart from that you can never know that a pointer points to a non-wrong location. And still experienced C programmers seem to be OK with using pointers.