Live data from Hacker News

Modern C [pdf]

icube-icps.unistra.fr

21–30 of 396 posts

Re: Modern C [pdf]

#21

Can any C programmers evaluate this book? I don't do a lot of C, so I can't really do it. Does it advocate good best practices? Does it talk about pitfalls? Does it overemphasize new, possibly less widely implemented, features? Does it do/not do anything else we should know about?

> Does it advocate good best practices?

That may come down to opinion. For example, type qualifiers are bound to the left.

Traditionally you would write:

    char *var;
They advocate keeping type on the left, name on the right, so:

    char* var;
A few things like that are covered under "Warning to experienced C programmers".

Personally, I prefer it, but have always done what everyone else expects, so there are no fights over styling.

> Does it talk about pitfalls?

Absolutely.

At a glance over, they talk about the unexpected way C treats truthy values (if it ain't 0, it's true), accidentally dereferencing to NULL, and even goes into goto, when it's good, and when it's bad.

> Does it overemphasize new, possibly less widely implemented, features?

Yes. They assume a C11 compiler, and state it in the introduction. At the moment, GCC and clang have some disagreements with how some C11 features should be treated, (GCC accepts a char or a char* for _Generic, clang requires it to be char. clang is more technically correct, but GCC is more flexible), and MSVC is still struggling to implement most of it. [0]

> Does it do/not do anything else we should know about?

I probably need a week to read it more fully, but I'll quote from the end of the introduction:

> Last but not least comes ambition . It discusses my personal ideas for a future development of C. C as it is today has some rough edges and particularities that only have historical justification. I propose possible paths to improve on the lack of general constants, to simplify the memory model, and more generally to improve the modularity of the language. This level is clearly much more specialized than the others, most C programmers can probably live without it, but the curious ones among you could perhaps take up some of the ideas.

[0] https://msdn.microsoft.com/en-us/library/hh567368.aspx

Edit: escaping

Re: Modern C [pdf]

#22

Earlier quoted context omitted.

If your a fan of the terminal I recommend writing a terminal program that scratches an itch of yours. Perhaps theres a shell script that runs too slowly? Or something in inscrutable awk that would be better as its own program.

Hmmm... Yes I'll have to give it some thought. I use Python for most of my scripting needs. I guess I've never had a need that's required better performance.

Even though it may not make technical sense to choose C, you may want to just use it to learn.

Re: Modern C [pdf]

#23

Earlier quoted context omitted.

Hmmm... Yes I'll have to give it some thought. I use Python for most of my scripting needs. I guess I've never had a need that's required better performance.

Even though it may not make technical sense to choose C, you may want to just use it to learn.

Yup. I'm going to make some scripts. Thanks. :)

Re: Modern C [pdf]

#24
post #12
post #10

Earlier quoted context omitted.

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditiona…

Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?

Re: Modern C [pdf]

#25
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…

> Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?

While Rust might be feasible, Go can't really provide libraries like SQLite: Go's C compatibility story is disappointing and awkward.

Re: Modern C [pdf]

#26
post #10

Earlier quoted context omitted.

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Sure, "systems programming" has a variety of meanings. But, there are a lot of areas where C was the obvious choice in the past but Go might be a suitable replacement today. Areas where concurrency and safety is maybe more important than raw performance: Databases (and there are many now written in Go, including alternative types of databases like time series, key/value, etc.), servers, etc. I tend to consider those…

Databases have been written in Java, too; but the combination of performance unpredictability (not something Go has addressed, since it is also garbage-collected) and a bad C compatibility story has proven to limit the reach of these projects.

Re: Modern C [pdf]

#27

I didn't use C much. What kind of features of are in the book that make it modern?

it is as much to do with language style, usage, and (it's subjective view of) good C programming conventions, as it is to do with modern language features.

Re: Modern C [pdf]

#28

Earlier quoted context omitted.

If your a fan of the terminal I recommend writing a terminal program that scratches an itch of yours. Perhaps theres a shell script that runs too slowly? Or something in inscrutable awk that would be better as its own program.

Hmmm... Yes I'll have to give it some thought. I use Python for most of my scripting needs. I guess I've never had a need that's required better performance.

Python has an excellent C extension api. I'd suggest taking a C library that does something you want and writing Python bindings for it.

Re: Modern C [pdf]

#29
post #12

Earlier quoted context omitted.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditiona…

Rust is more focused on C compatibility and simple (dumb) operational semantics than Idris and other dependently typed languages. Rust will never require GC, for example; maybe Idris doesn't now but is that a focus for them?

Idris can compile to c, it requires no runtime. You're probably thinking of Haskell with its RTS.

Idris is closer to ocaml in that regard.

I cough may have already tried using idris in a kernel module. (for fun, not for serious)

Re: Modern C [pdf]

#30
post #18
post #11

Earlier quoted context omitted.

It is indeed. But its more a polishing of C99 imo. At least annex k is optional now iirc.

The C standards kind of have a main theme, eg numerics (aka eating Fortran's lunch) for C99 (_Complex, restrict, variable-length arrays, type-generic math functions, ...). While C11 is indeed to some degree a polishing of C99, its theme is multi-threading.

Yep, I've not tried the c11 threads yet, pthreads tend to work for me and in kernel, well not like i'll be using c11 threads anyway. So its been a bit of a "maybe someday" task. :)
Post reply on HN