No posts so far for 3-2024....I have been brushing up on C++ skills.
After years of writing code in embedded C, which works fine for what we usually do, why C++?
I was talking with a talented DIYer at my friendly (and let's not forget) geeky meetup.
We discussed the 4011 based hardware debounce circuit--post here.
He was baffled: why not do this in software?
His advice--other professional engineers have told me this also: If you can do something in software you should do it in software.
Software is easy to change--hardware, not as much.
He emailed me his debounce C++ class which was only 40 lines, contained in a single cpp file.
I could follow the basics--maybe--and figured I'd port it to C, then thought, why, Stroutty, why?
It should be easy to attend an online C++ class and get to the point where I could port the debounce code and drop it into my current RP2040 project or whatever else I was working on.
Besides, I was a bit tired of troubleshooting hardware after a disappointing Moog HPF build and needed a different challenge.
So....I signed up for the C++ Mosh class.
I already attended an online Mosh GIT class I found useful. His C++ offering was affordable ($99USD for a three part course). You can find a free version of the Mosh C++ course Part I here.
Do the Monster Mosh....
Turns out it parts I and II of this 3 part class were good for C review and C++ basics, but by part III but the lack of source code became problematic; I was spending too much time typing Mosh's lessons into Visual Studio Community to see if they worked.
I stopped attending classes entirely after about a third of the way through part III where not only was it ridiculously painful and time consuming to type example code into my IDE, but some of the damn lessons wouldn't compile even after meticulous typing. Hello?
The forum for the class wasn't helpful either, some members were oddly rude and many basic questions (like--where the hell is the source code?) went unanswered.
$99 was still a good value for what I got, but, no source code and examples that don't compile?
Time to move on.
What Else?
Fortunately even if Mosh part III was the pits there was a ton of materials about C++ everywhere.
C++ references:
cppreference; Damn hard to follow for a beginner, and maybe for almost everyone, but, as I learned more C++, I could begin to sort of kinda of make some sense of some of it. Sorta. Kinda.
C++ for C programmers. Useful to me, since I am already OK at embedded C.
C++ tutorials:
TutorialsPoint this has become my go-to reference for learning. These lessons are super clear, lots of simple examples, and unlike Mosh Pits--this guy includes his source code. Yeah!
W3 C++ Tutorial -- who says these guys can only teach you to write HTML and CSS. Another good source for learning.
C++ video tutorials:
- Hank Stalica -- practical C++. Like for a college freshman.
- The Cherno -- a bit more advanced--you have to be OK at C++ to follow some of his C++--still, useful.
- Code Beauty -- easy to follow lessons and yes, she is a cutey.
- Caleb Curry -- whole enchilada here. This kid must have spent hours and hours and hours (!!) putting together these tutorials--we owe him our gratitude.
What Was Next?
With a few weekends and evenings of C++ practice I went back to some embedded examples (for instance an AD4725 C++ class for Arduino--here or AD1115 for RP2040--here) and was happy to see that for embedded open source C++ most programmers stuck to basics. No virtual classes, no friend classes, no lamda expressions, not even smart pointers. I could follow this.
Perhaps for embedded systems, the kind of stuff DiWhyers do anyway--we don't need/don't want crazy advanced modern C++ foobar. "Just the Class, ma'am".
I went back to the bench to see if I could rewrite the debounce C++ class that started me down the C++ rabbit hole--Could I get it to work with an RP2040 MCU?
The original code was written for a Teensy 3.1--which is based on an NXP MCU.
The RP2040's SDK handles interrupts quite differently; but how could this port be?
Turned out--hard. Very hard.
Interrupt handlers in C++ are oddly difficult to code (explanation here), but to make things worse, the PICO uses callbacks as Interrupt handlers, after a few hours looking into this, yes, C++ is, umm...err..., odd?, and I thought it made the most sense to write a interrupt driven debounce algo for RP2040 in C or continue to use hardware to debounce.
It would take too much time to sort this out in C++ and the resulting code would be overly complex, especially for someone new to C++. Really? Really. In this case: "C: the right tool for the job".
Next I went over a few recently C classes I wrote. For example, the C code for the MCP4922--what would be involved in porting that to C++? Sure, I could do it.
Right now I don't think I have time.
Moved on.
OUTTRO
After about a month--yeh, I am convinced--C++ sucks. It has the oddest syntax I have ever seen, is endlessly dense, endlessly confusing, has even has its own bizarre terminology (lvalue? rvalue? Storage class specifier? there are thousands of these damn things) along with a lot more to make a normal person trying to get some damn thing to work run screaming.
Worse of all, some of the C++ programmers I discovered on my month long journey have the atonal bebop jazz complex: "screw you if you are not as awesome and talented and smart as I am".
Right! Toot your trumpet, Ornette, while I cover my ears.
I still have no idea why C++ is so popular, nevertheless I will keep plugging away at it. Thank you Bjane, may I have another? I am that kind of masochist.
No comments:
Post a Comment