51–60 of 231 posts
Know that third party libraries often are not a solution. Often have a limited lifecycle, departed authors, and 90% of code you are not using, yet have to consider in regards of security etc.
In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values). This comes up incredibly frequently, and having it be second nature will benefit you. A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your met…
If by low level you mean embedded systems programming, you will definetly need to be proficient in C. The other knowledge depends on the product that you will make. For example I work in the automotive industry, where you need to be interested in cars and how the different parts work. Knowledge of electrical engineering and control theory is also valuable. There is a good book about it if you wat to learn how cars wo…
I don't do embedded systems, but as a self-respecting software engineer, I am intending to develop proficiency in C/C++ over this next year. Does anybody have any recommended books/courses/projects?
Also 21st Century C has been recommended, and it goes into tooling as well.
In embedded and systems-level programming, something I find indispensable is knowing what values fit in what types (for example, an 8-bit type can represent a maximum of 256 values; a 16-bit type can represent 65536 values). This comes up incredibly frequently, and having it be second nature will benefit you. A lot of the time, this gives you a starting place for how your inputs and outputs should look, what your met…
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…
Without that though, performance is really really bad. The inner loop of a motor controller is no place for them...
Earlier quoted context omitted.
A quick word of warning: be sure to treat C and C++ as two completely separate languages that just happen to have similar syntax. Yes, you can use C++ as "C with classes" (I and many others sure have at times), but you're doing yourself a disservice most of the time if you do.
Huh. I always perceived C to be a subset of C++.
But the major point is that there are almost always safer or more ergonomic ways to do things using C++ features that are not present in C.
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…
With that being said, your list of things to know are all things I have to know for my job (these are things almost all programmers should know, in fact) and I would not consider myself a low-level or systems programmer, just an application programmer.
Earlier quoted context omitted.
A quick word of warning: be sure to treat C and C++ as two completely separate languages that just happen to have similar syntax. Yes, you can use C++ as "C with classes" (I and many others sure have at times), but you're doing yourself a disservice most of the time if you do.
Huh. I always perceived C to be a subset of C++.
Because sometimes that's annoying, things can get less type safe, but in your head, there's a C++ program that you're representing.
If by low level you mean embedded systems programming, you will definetly need to be proficient in C. The other knowledge depends on the product that you will make. For example I work in the automotive industry, where you need to be interested in cars and how the different parts work. Knowledge of electrical engineering and control theory is also valuable. There is a good book about it if you wat to learn how cars wo…
I don't do embedded systems, but as a self-respecting software engineer, I am intending to develop proficiency in C/C++ over this next year. Does anybody have any recommended books/courses/projects?
> as a self-respecting software engineer
Then you probably already know more about C than you realise: if, while, for, etc. all work the same as most other languages.
What you're probably not used to is needing to define functions in advance, pointers, and memory (de)allocation.
If you learn by doing, then with google and github, you can create a few simplified versions of unix utilities (cat, ls, grep -F).
If you're on Windows, I recommend using a Linux VM, WSL, or Cygwin - it's easier to setup than the C tooling in Windows (and you're stealth learning something else).
Once you know C, you can then move onto C++ (I stopped at C).
I would say learning a bit about the security implications involved. You don't have certain things given to you like other languages. You have to watch what compiler flags you use, like someone turning off stack cookies, not using clang's sanitizers. Check out https://clang.llvm.org/docs/AddressSanitizer.html it would have prevented the Heartbleed vulnerability if it existed at the time. You need proper bounds checki…
If that was true, then so would Valgrind have, and Valgrind was in wide use at the time.
It was however more complicated than that. If my memory serves me right - OpenSSL had its own memory management.
You should learn C. Ideally, you could learn C++ as well, but I think it's best to learn C first. And then treat C++ as a completely separate language. Rust is a good thing too, but it's a little too soon for it to be broadly useful. Then you should learn Unix. From an understanding point of view, I think it's probably better to learn something like FreeBSD, NetBSD, Xv6 ... Linux is very pragmatic, and very general,…
- Embarrassingly low-level (chip developers): OS, C/VHDL/Verilog, MA, DS, GPH, EE, Apathy, SE
- The in-betweeners (kernel, device, storage developers): OS, C, MA, DS, GPH, Apathy, Crypto, SE
- Low-Low-level systems: OS, C, DS, GPH, Apathy, Crypto, SE, FTDS, MSG, NW.
- Low-High-level systems: C/Rust, DS, GPH, Apathy, HDS, Crypto, SE, FTDS, MSG, NW, TL.
- Unicorn rock-star systems hacker (perhaps only a handful of these creatures exists :-): Multiple OS, C/Rust/JVM/Erlang/Haskell, Multiple MA, DS, GPH, EE, Crypto, FTDS, MSG, NW, HDS, SSE, TL.
Abbreviations used:
GPH = Good Programming Hygiene
EE = Electronics and Electrical Engineering
OS = Operating System
MA = Modern Assembly
DS = Data Structure
FTDS = Fault-Tolerant Distributed System
MSG = Messaging System
NW = Networking
TL = Toolings (the darlings of UNIX)
HDS = High-Density Systems
SE = Security Engineering