221–230 of 231 posts
Earlier quoted context omitted.
> I learned it with "Advanced Programming in the UNIX Environment". Agreed. APUE is perhaps one of the best book available covering SUS, POSIX layer in detail .
APUE is good, but I believe it has now been superseded by The Linux Programming Interface.
Nice. I'll check it out.
Earlier quoted context omitted.
I like to think what is JSON to Javascript is C to C++ (not capability wise). JSON and Javascript are completely, entirely different things even though JSON is technically a subset of Javascript (every valid JSON sentence is a valid Javascript sentence). C and C++ are extremely different languages -- mostly due to cultural reasons -- even though every valid C program is a valid C++ program (not strictly true, C and C…
Can I be pedantic? If I'm wrong someone will correct me and I'll learn something. Json is not exactly a subset because it supports representation of numbers of any precision. JavaScript will convert to an IEEE 754. But it's up to a json deserializer to decide how many decimals to use. I think.
Earlier quoted context omitted.
> Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. I don't disagree, but at least anecdotally a lot of the shops I've been involved with/worked with are really excited about Rust and Go. A previous employer that used C++ exclusively has even shipped a few Golang based tools, and is planning to introduce it into the main product soon. No new projects are being started…
Golang is garbage collected. I thought due to this, system programmers don't like it.
Earlier quoted context omitted.
There aren't as many jobs in the embedded space as there are for higher level software. Nowadays, lots of new embedded processors are hitting the market and there will probably be a shake-out sooner or later. So the embedded space isn't necessarily more stable than the web based stack. Lots of the processors are getting huge with lots of memory, faster and more capable cpu's; all of which will require programming at…
These are valid points for embedded systems without latency/power requirements, but I want to add that many embedded systems require rolling custom assembly and writing everything else in C to avoid the overhead of other languages and meet battery life and/or performance requirements.
Earlier quoted context omitted.
> Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. I don't disagree, but at least anecdotally a lot of the shops I've been involved with/worked with are really excited about Rust and Go. A previous employer that used C++ exclusively has even shipped a few Golang based tools, and is planning to introduce it into the main product soon. No new projects are being started…
Golang is garbage collected. I thought due to this, system programmers don't like it.
Earlier quoted context omitted.
Maybe it is just me, but I've seen this issue multiple times where a programmer used a regular expression thinking they were clever, only to have it backfire later when there was some corner case not covered by their regex (which likely would have obviously been caught if they had just taken the time to write out each case as an if statement). You're usually just gaining complexity in exchange for fewer lines of code…
A good in-between option is a parser generator like Ragel , http://www.colm.net/open-source/ragel/ This takes in the definition of a regular language as a set of regular expressions, and generates C code for finite state machine to parse the language. You can visualise the state machine in Graphviz to manually verify all paths, making it much easier to spot hidden corner cases, while being a lot quicker to code than…
From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…
I agree with you on everything except regular expressions. I would hope a system programmer would move beyond regular expressions towards safe, linear complexity binary parsers. And I would also add fuzz-testing to your list.
If you don't know what ASLR is, you're not ready for systems programming.
Earlier quoted context omitted.
Also the ability to understand and check the performance impact of these choices. For example at a old job on an embedded motor controller the previous engineer had learned 'floats are slow never use them on a microcontroller' and went and removed them from the code wherever he found them. However in the motor control update loop this meant using longs (or possibly even long longs, I don't remember) in a couple calcu…
Fixpoint arithmetic is going to be significantly more efficient than floating point in many cases, except where you need to use relatively-uncommon operations/functions (which are hardware-accelerated in the FPU), or in cases where the same value might span multiple orders of magnitude (i.e. a direct win for the floating point representation). The inner loop of a microcontroller is not generally one of these cases, t…
Anyway a bit toggle tells all, and if you're making speed optimizations you should be checking that things actually got faster.
Earlier quoted context omitted.
K&R,and Richard Stevens's books
Please, please, please don't suggest people use the k&r book to learn C. It is one bad practice after another and many of the suggestions in that book have given C much of its reputation for buffer overflows, stack smashing, etc.