If you can actually do that, it reflects positively on your dependency's ability to make simple cases short and easy. Many libraries and frameworks actually don't.
It also requires several megabytes of standard library, kernel, operating system and compiler, but the point is that you don't have to write them. That's why you use libraries.
It's unfortunate you can't just write something like:
FIRE(args) {
// ...
}
without the explicit registration step. Unfortunately in this case the macro FIRE should first declare the fired function, then main, then defined the fired function, and this would be problematic because the definition can't have the default values for arguments again. I can't see a way around that.
Funny, jut a couple days ago I started using dotnet's System.CommandLine.DragonFruit which is similar in design philosophy to this - a main function with typed parameters and extra annotations. I would have never thought about this type of approach, or if I did I likely would have rejected it outright in favor of more typical classes / functions to do it, but I admit it's convenient for a quick tool.
I was wondering the same thing. Perhaps he means all the extra "fire::" annotations one needs to put in place in function parameter lists as well as the ultimate dispatcher instatiating cpp macro? Really there is always at least 2.5 with the #include <fire.h>, later macro and annotations.
https://github.com/c-blake/cligen achieves the actual 1-line of code dream without extra annotations and even leveraging existing API documentation and even colorizing said rST docs in terminal generated help output. { Of course, that one line might be an "import cligen; dispatch(foo)" which is arguably denser than most people would format it. } One usually wants to add some per-parameter help, though, unless your parameter names are always much more descriptive than "x" and "y".
The last line calls fired_main and is the full line.
The definition of the function fired_main is similar to the definition of the function main, so it is not an extra line that is needed. But about half of the line deal with describing the command line arguments.