C++

by

Signs of a simpleton having fun with a new microcontroller:

  1. Write a program that makes the LED blink like a mother fucker.
  2. Write a program that spams a hello world to USB serial.
  3. Write a Read Eval Print Loop over USB serial.
Compared to what I’ve done in C with simpler micros like the 8051 family, I’m finding the RP2040 really damned nice. Not only because of the Cortex M0’s horse power, but because of the really nice library that comes with the Raspberry Pi Pico. For the hell of it, I decided to abuse it with some simple C++ by for the REPL just to see that C++ I/O and string handling, does in fact work.
Of course, me being me, I ended up with a really simple set of commands:

static string evalline(const string& line)
 {
     if (line.empty())
         return “”;
     if (line == “monkey”)
         return “Willow?”;
     if (line == “monster”)
         return “Corky?”;
     if (line == “sweet”)
         return “Misty?”;
     if (line == “help”)
         return “Try nicknames with fur”;
     blink(100);
     blink(100);
     blink(100);
     return string(“Unknown command: “) + line;
 }

Because why not? 😜

by

New safety rules in C++ Core Check 

While the for loop part may be a bit spotty, in the sense you should be paying attention and know which you want when writing the statement. I have to admit I would have liked the auto thing.

I’ve mainly relied on C++14 since about 2016 for my C++ use whenever possible, and sometimes newer because of standard library. While catching up wasn’t as painful as I thought, aside from how long it’s taken for C++17 to trickle through various Linux distributions, there were a few things I found myself watching closer.

One of these was the way auto typing copes with references. I learned pretty quickly to watch my syntax  when using auto. If a real warning was available: it would have been much faster to notice the distinction. In my code, you’ll usually see auto used when the type would be redundant salt. But we usually want our sugars to not to have unintended pains, lol.

The code samples on the switch/case part also makes me remember just how verbose C’s simple switch/case statements are by today’s standards. Damn it, now my kind is flashing to SML….lol

My cxxversion and stdheaders

by

 In various bits of code: I’ve been using these headers to solve the “__cplusplus says yeah, but actually compiling says go to hell” problems. Because sometimes the macro tells you one thing and actually trying to preprocess and link makes naughty hand gestures on the systems I encounter.

Finally, I’ve gotten around to sticking these in their own repo.

Which is much nicer than going: “Which project did I last update that in?”

Random LOL

by

In porting an old multi-headed hydra, I found myself cackling.

Somewhere down in the beast’s HAL, is an utility function that returns the device name. This is what I found:
if (access(“normal device”, F_OK) == 0) {
    strcpy(devName, “normal device”);
} else if (access(“device not used in many years”, F_OK) == 0) {
    strcpy(“devName”, “device not used in many years“);
}
And in realizing why the stack trace was in such a simple function, I bust a gut when I noticed the quotes in the lower string copy. Ahh, the joys we inherit ^_^.
by

Over the years, I’ve screwed with a lot of build systems. Both in the course of my own projects and other people’s, and I’ve come to a conclusion over the past fourteen years.

At best: you can reimplement make poorly. At worst you can reimplment half of autotools, poorly.

That’s pretty much what I’ve seen. Thus as time has gone on, I see it very hard to do better than good old Make. Especially when the GNU version has about five hundred pages worth of voodoo to appease even the worst masterbaters, and the need for autotools is kind of waning IMHO.

Enter ninja.

What I’ve generally found with Ninja is that it’s very simple. Like C: the little bit of syntax you need to remember is a small quantity. Opening a build.ninja file is probably enough to grok what’s going on if you’ve ever used an actual build system that involves editing files.

Likewise answers to questions that tend to make it easier to build a wonky, hellish, broken build monstrosity, tend to be “No, you can’t because that would make this slow”. And let’s face it, if you want much more than a relatively simple Makefile, you’re probably building a case for pain.

Based on the past year, I think ninja will be sitting next to vim and dump in my toolkit of loved and trusty computing companions.

by

Draft FAQ: Why does the C++ standard ship every three years?

While Herb Sutter’s answers might be a tad strict I have to admit that I am pleased with the results they’ve been shipping.

C++14 makes a pretty damned good working language for the environment that I work in. If twiddling things forward to C++17 wasn’t a bunch of toolchain wrangling for my own sake more than customer driven, I’d be using it. This leads to reading the reference and thinking “Yay, someday!” as new features trickle out over the three year release cycle.

Over the years between C++98/03 and C++11 new toolchain releases usually revolved around their features. Like people agreeing on template vulgarities or improvements to code generation. Today I tend to be more interested in where the standard is headed, and what runtime library and compiler versions actually implement a given version of C++.

By contrast a very long time ago: it was just a plus if the compiler supported C89 and most of C++….lol

by

Right, premake4 is one of my favourite ways to build C/C++ stuff but tonight I’m thinking it has a moron involved. You can specify a project as being one of four kinds: ConsoleApp, WindowedApp, SharedLib, StaticLib. The documentation here states that this likely means /SUBSYSTEM:WINDOWS will be passed to link.exe, and indeed it is. That is how you say call WinMain and do any other I’m a GUI app magic for Windows; other wise you get a main and a command  prompt; simply put.

This FAQ entry on the other hand, is just retarded.

by

I guess like many, this morning I learned that the world recently lost one of it’s biggest contributors. I do not mean Steve Jobs, a man with his own important legacy. Dennis MacAlistair Ritchie has died, he was more commonly known as ‘DMR’ or just ‘Dennis Ritchie’. A G+ entry by Rob Pike is the earliest reporting I’m aware of, but I can’t say I expect this sad news to be found on TV.

Dennis Ritchie has a place in history that few men have ever achieved, because his work helped change the world. I am a young man compared to the late DMR but I does have an interest in history. If it wasn’t for this mans work, I doubt that I could be writing this journal entry, because he helped to enable so many elements that make it possible.

His most famous programming language, C, was so pervasively popular, that I knew of it before I learned to program. My first programming language (C++) was derived from it. A big part of how I fell so deep insane with computers was learning about how C and Unix became self hosting. That  means you could make C and Unix using C and Unix, in laymans terms. Back then that was  almost like revolutionary – today it’s like sliced bread. We take it for granted but someone had to help show us the way; then people started to use it everywhere.

Through C, we gained countless programs. Most Unix operating systems are written in C, most other operating systems are written in C or finally grown from one that was. Unix, DOS, Windows, Linux, OSX, your iPod, your iPhone, your iPad, our Android. None of it would exist just like it does. Most of the stuff we do every day involves C programs, be that reading e-mail, playing games, surfing the web. It is even normal for other programming languages to be implemented in C. The defacto standard Perl, Python, and Ruby included. It is so normal that writing a language implementation in itself is not so big anymore. C is so pervasive that it is also inescapable in other languages: their is almost always a way and a need to interface with C code. Hell, today you might even have C code involved in your toaster. It is that important a programming language. If you ever used a computer or an embedded system, you have probably used software written in C, or are old enough to remember what it was like before punch cards.

C is perhaps the single most important language since programmer’s stopped writing in raw machine code. In fact, sometime after that we stopped writing in assembly and I know no one who goes lower level than reading the machine code. A common portion of C syntax is practically our linga franca—even if C is not a shared language, the syntax (which grew from prior languages) is also widely used and an alternative to pure pseudo code.

Maybe a lot of young programmers don’t know C, or skip it. I love it. It is one of the most beautiful languages that I know, despite it’s trappings. Perhaps some of the greatest lessons I learned about my craft, was that learned from C. Perhaps another was the humility of it’s creator.

Somehow, I doubt his other works will ever be as well known as C, or things he was a big part of (like Unix), but maybe people will study them and see what they can learn from the work of a legendary hacker, like Dennis Ritchie.

Cassius is now on GitHub!

by

While a very important girl was off visiting her grandparents, I resurrected work on Cassius! Thanks to a few nights and occasional Saturday afternoons, the interface is maturing to the point where I can almost use it, so I’ve decided to put it on GitHub.

Old code never goes away, it just goes back to the compiler.