3 ms·

Those don't seem like "these days" things. In fact, some is much more "old days". Glib is just another library like any other, and POSIX is just a library plus

Those don't seem like "these days" things. In fact, some is much more "old days". Glib is just another library like any other, and POSIX is just a library plus specification of the details any platform would have to specify. And if you're not on something that tries hard to look like a *nix, POSIX mastery isn't going to help you. Autotools is a plague slowly being eradicated, the problems it ostensibly solved have become far less serious to the point that they can be effectively dealt with by less insane means. Make is increasingly replaced or supplemented with other tools (cmake, scons, ninja, ant if you're crazy), especially when builds start getting complex. Heavy macro usage is not some modern idiom. In fact, "these days" it's indicative of laziness, poor design, premature optimization, or a religious refusal to use an OO language for OO code. Sadly there is a lot of this code out there, but yours doesn't have to be part of it. If writing your application involves many and/or complex macros, you should reconsider your approach.

bluetomcat 12y ago
I wouldn't regard POSIX as "just another library". It is the interface between your program and the operating system. In order to gain a healthy understanding of things like memory mapping, signals and process control, you have to go beyond the corresponding man pages.
- nknighthb 12y ago
  That has nothing to do with C. You would need to do the same thing in any language on any platform.
  - bluetomcat 12y ago
    Most higher level languages do have wrappers around these calls, but you rarely have to worry about things such as async-signal-safety or EINTR, for example. Knowing why such things are problematic isn't of much interest to the average Python programmer, while essential for writing correct and safe C code.
    - nknighthb 12y ago
      I wasn't talking about "higher level languages", really. Still, you have made a strange statement. Most obviously, if you don't worry about EINTR in Python, your code crashes. This was, in fact, the subject of a recent draft PEP (475) that generated a fair bit of discussion but not much consensus. To the extent you're better off in Python or any other high-level language than in C, it's because things are removed from your control. Obviously, if you can't do something in a language, you can't do it wrong. That is uninteresting. And of course EINTR and much signal behavior is POSIX-specific -- as in, you may not even have it (or necessarily anything like it) on other platforms. This, again, is not a "C" thing. All the world is not POSIX.

bluetomcat 12y ago

I wouldn't regard POSIX as "just another library". It is the interface between your program and the operating system. In order to gain a healthy understanding of things like memory mapping, signals and process control, you have to go beyond the corresponding man pages.

nknighthb 12y ago
That has nothing to do with C. You would need to do the same thing in any language on any platform.
- bluetomcat 12y ago
  Most higher level languages do have wrappers around these calls, but you rarely have to worry about things such as async-signal-safety or EINTR, for example. Knowing why such things are problematic isn't of much interest to the average Python programmer, while essential for writing correct and safe C code.
  - nknighthb 12y ago
    I wasn't talking about "higher level languages", really. Still, you have made a strange statement. Most obviously, if you don't worry about EINTR in Python, your code crashes. This was, in fact, the subject of a recent draft PEP (475) that generated a fair bit of discussion but not much consensus. To the extent you're better off in Python or any other high-level language than in C, it's because things are removed from your control. Obviously, if you can't do something in a language, you can't do it wrong. That is uninteresting. And of course EINTR and much signal behavior is POSIX-specific -- as in, you may not even have it (or necessarily anything like it) on other platforms. This, again, is not a "C" thing. All the world is not POSIX.