I had a similar experience writing image decompressors. There wasn't enough to internally manage for rust to provide any benefit, and the gritty fast algorithmic code is just simpler to do with C++. C wasn't going to get me the flexibility and generic patterns I was going for.

what %ge of C++ features did you use for that ?

I've got a bunch of thermal printers in my work lab that definitely don't have this but they all support ESC/POS. They're all currently produced kiosk style printers.

Some of these show up as USB to serial converters and while you do need appropriate kernel drivers for that, they'll never be recognized as a "printer". Still usable though.

This could be plain software on any computer with network and a serial port. Not sure if the product is tied to RP hardware but it certainly wouldn't have to be. I work with thermal printers controlled by significantly less powerful hardware still running Linux, and still easily hit physical speed limits. I'd rather see this as a pure software daemon that can run anywhere.

Wait until you hear what C compilers try to do if you divide by a constant. Hint: they don't need to use a division instruction in most cases.

Google for contacts and small stuff. Photos get copied to a home server which itself gets backed up. I've used rsync front-ends, non-standard apps which I don't like (PhotoSync). It's been plain SMB shares accessed through CX Filebrowser recently, I haven't cared to get fancy. I'm always using this SMB share with various devices anyway because tons of things "just work" like VLC on Chromecast.

How do you copy the photos to a home server?

I find this kind of thing most useful for microcontrollers and real-time embedded systems that don't require full networking. I've used many of these concepts but maybe not all at once on what many would call "bare metal" systems with no OS. Audio gizmos like cheap synths, LED nodes, things you want booting really fast with well-bounded functionality. An OS can get in the way with this kind of system if all you really need is some timers and simple I/O. You may still want a primitive scheduler, sane interrupt dispatching, and filesystems.

Interesting. Yeah for me it's like RISCV, at the end of the day if it runs windows/Linux do I care what's underneath. I gotta get there to know why it matters. Other than the challenge of doing it.

Pool allocators don't walk the list or search anything though. All interactions are only at the list head and O(1), as all free nodes are just that, free and equal.

Then it might be a misnomber. Calling it "stack" instead of "list" might be better.

That is a fair comment.

While the most precise naming might be "a singly linked list representation of a stack", "free list" (https://en.wikipedia.org/wiki/Free_list) is an ancient term of art for this problem.. so much so that wikipedia (at least the version today) even suggests "freelist" all one word as a spelling.

The initial linking together of all free space (also cache friendly, btw) is often called "threading the free list", although this terminology is less standard than "free list" itself.