I'm implementing another AGROS-based doodad, and once again using SCPI commands to communicate with it - not that SCPI is particularly wonderful, mind you, especially when moved outside its original HPIB context, but somebody else is going to be communicating with the gadget using LabVIEW, and I might as well make his life easier - and, inevitably, I run into some syntax I hadn't needed to handle before.
I already had handy parsing functions for numerical arguments and such, but now I need to handle channel lists: (@1, 3, 6, 12:17, 94) and like that. And, given that the range of channel numbers can be quite large (and that the standard calls for the order being significant), I can't just set bits in a bitmap.
First go was to stick parsing code in the handler for each command or query that needed to handle such lists, but that opens a can of maintainability worms, as well as being wasteful.
I was almost thinking it was time to learn enough C++ to handle this sort of thing, and then redo the whole SCPI subsystem in C++... but that's another can of worms. Still, the concept of handling it the way I would in Ruby, i.e.,
cmdline.eachify_channel_list do |chan|
has a certain appeal.
Well... how about if I write an iterator with a callback? Straightforward enough, except: C doesn't have lambda expressions, so I'll need a named top-level function for each callback case, or some sort of multi-function callback function. Ugh.
But wait! I go rummaging through the current GCC documentation to see what extensions are on offer (AGROS is highly GNU-toolchain-specific anyway), and I find that it now supports full-on nested function definitions!
Which is rather more than I need for the purpose at hand, but it's a convenient way of having a small function, about whose name I need not worry, to handle callbacks from the iterator function.