81–90 of 231 posts
C
You may not need to do new work in it, but the large body of existing stuff is in C and that's not changing for a while.
If you want to move into the mid-stack then Java is pretty good these days, python too.
Earlier quoted context omitted.
Huh. I always perceived C to be a subset of C++.
FWIW I think he's wrong. Basically, when writing C, you should write code the same as if you'd write it in C++, except that you're using 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.
Treating C as a sort of "portable assembler" is a lot better, although it runs into UB problems (see DJB on this subject).
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.
For what use? It doesn't make sense to write your own FFT library buy it from NAG.
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…
What if -and I'm sorry to hijack- by low-level OP means a position as a C/C++ developer (asking for ~a friend~ me)? I've always been insanely attracted to the C variants and messed around with them to minor extents, but what might someone _need_ to know to be competitive if they're trying to make a move to that area of SE?
It's worth picking up some basic gdb skills. Use of ddd can help with this. On windows you can use VS for most of this of course. Picking up the basics of valgrind will also help you.
Get comfortable with the preprocessor. Get comfortable with Makefiles. Get comfortable pulling in library headers and binaries as needed.
Errr....
I was (mostly) a C programmer for over a decade, but that's about all I can think of right now!
--edit--
And someone below has just triggered me - FFS use stdint.h!
Earlier quoted context omitted.
Programs written in this mindset might be the number one reason why C has a bad reputation. Of course, if you just emulate what other languages automate for you, you should better write in these languages. But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requir…
What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…
MISRA C standards, popular in embedded projects especially automotive, ban the use of memory management altogether.
The whole point of RAII is that the compiler manages it for you as far as it can. This is impossible in C because you have to do it manually. You might end up writing malloc() at the top and free() at the bottom of functions but that's the opposite of RAII.
Linked lists, bitcounting problems (which is covered in the first few chapters of K&R), etc. are all still popular.
The biggest issue you might have is the difference in salary and available positions you're going to see going from FANG Backend Dev at 5 bazillion a year or whatever it is now to 80-120K.
Earlier quoted context omitted.
Are the jobs still there or are they disappearing? I am bored of the churn associated with stuff higher up the stack. I would prefer to master a craft rather than chase new fads every few years.
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…
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?
Earlier quoted context omitted.
Programs written in this mindset might be the number one reason why C has a bad reputation. Of course, if you just emulate what other languages automate for you, you should better write in these languages. But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requir…
What. What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII? Edit: "But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow neve…
Then all the implications like exceptions and needing to implement copy constructors, move constructors, etc. in each little structure.
As to what C project doesn't just emulate RAII: Take any large C project and you will likely find diverse memory management strategies other than the object-oriented, scope-based one. Also, other interfacing strategies than the "each little thing carries their own vtable" approach. The linux kernel is one obvious example, of course.
But I also want to reference my own current project since it's probably written in a slightly unusual style (almost no pointers except a few global arrays. Very relational approach). https://github.com/jstimpfle/language. Show me a compiler written in RAII style C++ that can compile millions of lines of code per second and we can meet for a beer.
> The reason is, C++ doesn't impose anything on your program structure that C doesn't
Of course you can write C in C++ (minus designated initializers and maybe a few other little things). What point does this prove, though?
Earlier quoted context omitted.
Huh. I always perceived C to be a subset of C++.
C enum values are convertible from int; C++ enum values aren't. This is one of the biggest differences in fairly idiomatic C code and has been the case for a very long time (i.e. not dependent on newer C features not being in C++). #include typedef enum EFoo { FOO_A = 1, FOO_B = 2 } TFoo; int main() { TFoo foo = FOO_A | FOO_B; printf("foo = %d\n", foo); } This compiles in C but not C++.