Regarding #libsibo, I'm trying to decide on the way forward for the project.
Currently it's in #Arduino C, so there's the odd class, but it's mostly regular C. It'll run on an Uno, ESP32, or a Pico/RP2040.
I've wanted to drop the ESP32 support for ages. But I'm wondering about dropping Arduino support and switching fully to the #RP2040 SDK. For the Uno, I can just maintain the old .INO file for basic functions.
If I go C, I'll have to refactor the classes. But is going full C++ a good idea?
Also, I'd quite like some of #libsibo to be usable on a desktop OS as well as the RP2040.
For example, most of siboimg/fefstool's back-end functions will end up in libsibo (and, in fact, already have), so surely it makes more sense for fefstool to just call libsibo?
I'm sure someone's going to say "use Rust." But my brain can't even handle switching to Go right now, so I think rewriting my current projects in Rust is probably a leap too far.
@M0CUV The more I learn about "real" C++ (rather than my current "C with classes" approach), the less I like it. (Who the hell thought the ”cout <<” syntax was a good idea?!) But it's pretty essential knowledge for fiddling with a large proportion of FOSS software such as MAME.
Using a sane subset in my own work sounds like an excellent idea!
Also, using a programming standard from 2011/2014 sounds positively futuristic to me, considering I've been using TopSpeed C! 😂
The Last Psion | Alex
Matt Gumbley