Oddbean new post about login | logout Glad you found the one for you. Keep my npub if you want to do more C/C++ things :) C++ is everything some dream of C with all the modern OOP. Yeah it's a beast, even systems developers admit that. Since C++ is a superset of C you can abuse C++ with C patterns (and many do because when in doubt just access memory directly) C++ adds many complicated features as security mechanisms to leverage the compiler (templates specifically) to help you make better patterns if you want to. Imo C++ is a complexity short-cut, steeper initial learning curve, but dividends in high level applications compared to writing C. That an C++ has actually package management solutions where C doesn't really. Finally since C/C++ compilers literally take individual C files, assemble them, and then implement machine code (translational units) called object files, it's a super manual process which is where GNU Make and CMake come in, both of which require their own languages too. Noscrypt (my nostr cryptography library) has like a 600+ line CMake file just to orchestrate the build lmao. So you're not just learning to write code in the language, you're also learning the compiler and build system. Before I even write a line of code for a hardware project I read the manufactures' compiler manual. Because you may not realize that int is actually not an int at all, or the register keyword will cause stack issues because registers are limited. In C it's forced and for good reason, but not everyone needs to learn system level programming to get the job done @finrod can speak to this as well I'm sure
yeah that's how I felt. To do A I need to do B and learn C. Doing B requires doing D,E,F.. By learning C you need to learn also G, H, and so on. And the tree becomes big, and at the end I forgot what I wanted to do lmao.
none of this needs to be understood to write reasonable Go code it's only really when you start shuffling large amounts of memory that Go's GC fails to work in your favour and you need to start to look at schedulers and buffer freelists c++ boost libraries are a constant breaking change party that never stops, and c library versions don't seem to be much kinder but at least they are a bit slower moving if your task is analytics, you want simple languages, that's why most mathematicians just use mathematica, but if your data crunching is memory heavy you need an efficient language and preferably binary not interpreted (or at least VM based) C really is mainly for fast performance and low level systems stuff, and anyone who tells you that you need to understand OOP garbage to write systems code is just straight up lying because windows, mac and linux kernels are all written in C, not C++, for a reason (that being unintended complexity) i wish OOP would just die, it was a dumb idea that Jobs and Gates got hooked on because of Smalltalk and it was possibly the least performant model possible for GUI programming, structural typed and concurrent sequential processes are much more simple to reason about and compile for these same purposes (i used to be an amiga user as a kid, and it pained me so much that a C compiler and the manuals cost more than 2x the hardware) it was just an accident of history that ONE GUI development project that both apple and microsoft's CEOs went to check out at Xerox used an interpreted OOP language and now we all suffer from this eternally
> C really is mainly for fast performance and low level systems stuff, and anyone who tells you that you need to understand OOP garbage to write systems code I haven't seen any real system level code in any sort of OOP, I'm sure it exists, but very rare from what I can tell. The best case is Arduino libraries really what come to mind, and that's just so things feel more comfortable to a broader range of developers. OOP is a core of CS fundamentals in college (or at least was the whole time I was there). Only the EE and CPE people learn in functional stuff because thats all we used.
Not sure how much I can add to this. @ChipTuner covered most everything I would have to say. In my personal experience, I only started appreciating the complexity of C++ with respect to C - in other words the ++ part - whenever I would encounter the limitations of C. At this point in your learning process, you shouldn’t fret about what happens under the hood with C/C++ programming like target CPU architecture, build systems and makefiles, talking with the kernel, all this is too overwhelming at first. I suggest that you begin by porting basic python code to C/C++ Like reading keyboard input, string manipulation, data types and structures, reading/writing to files, sockets, threads, etc. You start with things step by step. And then you decide how deep you want to go.