6 ms·
Create a fully functioning command line interface with 1.5 lines of code
- Jare 6y agoFunny, 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.
- Kiro 6y agoWhat does 1.5 lines of code mean?
- ngold 6y ago>Note that parsing and conversion takes up just 0.5 lines of fired_main().
- setr 6y agoI think 1 line to modify the function sig, and .5 to call the library Its purely marketing math, I think.
- cb321 6y agoI 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 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".
- anigbrowl 6y ago'Give me your attention'.
- hibbelig 6y agoThe 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.
- deleted 6y ago[deleted]
- butz 6y agoThe example is clearly 9 lines long and included fire.hpp has 703 lines of source code excluding comments.
- giomasce 6y agoIt 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.
- x87678r 6y agoI'd love a good library to handle an interactive prompt and state machine. You know press 1/2/3 for x/y/z etc. Java especially
- bdcravens 6y agoI can also write a fully functioning web application in 1 line of code if I exclude how big each dependency is.
- brazzy 6y agoIf 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. That's what this is about.
- gumby 6y agoNice. boost::program_options needs a rethink for modern c++
- popotamonga 6y agoAnything for C#?
- thiagocsf 6y agoThis reminds me of Click for Python in that the CLI is built based on the functions that describe the commands and arguments. Click uses decorators though. I don’t know what the C++ equivalent could be.
- femto113 6y agoIf we're playing CLI golf why not use macros to make it even dryer? int fired_main(int x = fire::arg("-x"), int y = fire::arg("-y")) could just be int fired_main(int fire_arg(x), int fire_arg(y)) with something like #define fire_arg(v) v = fire::arg("-"#v) The C preprocessor is still the thing I miss most when working in any other language.
- ncmncm 6y agoSomebody should explain that std::endl instead of '\n' is pointless, verbose, and also slow.
- giomasce 6y agoIt'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.