Home

Welcome to the cli wiki!

In this page there are some random notes about the library. The target are mainly the contributors. Eventually, some of these thoughts will end up into the CONTRIBUTING.md, README.md and other repo files.

Goals (and non goals)

• The library goal is to provide an interactive command line to C++ programs (in particular to asynchronous programs). The behaviour of the CLI provided should be as similar as possible to bash as for as history and autocompletion. One of the more useful feature for servers and embedded software is the telnet server, i.e., its capability to provide a cli through a tcp port, so that a remote user can open a telnet client (or netcat) and interact with the cli. Moreover, we try to keep the menu structure as flexible as possible.
• I started this library out of a specific need of mine, after searching in vain for something similar. After developing it, I though it would be nice to share it with other developers that might need it. I wrote this library out of a specific need, and not to show off my C++/design/other skills. Please, remember this before writing a comment, open an issue or doing a pull request.
• The library must remain compilable with every c++14 compliant compiler. This is because many projects already using the library are constrained to old compilers. For this reason, I can’t accept pull requests exploiting C++ features newer than C++14 standard. The same applies if you rewrite any C++17 features and include it in the library: unless this is the only way to implement a very useful feature of cli library, I won’t accept the pull request.
• TODO ...

Roadmap

TODO

FAQ

Isn’t the name “cli” a little bit too generic?

Yes, it is. The library was developed initially to satisfy my needs, to be included just in my projects. For that purpose, “cli” was perfectly fine. Now that the library starts to get used by other people, the original name starts to show its limits. First of all, it’s difficult to find it on google. Then, the term “cli” is ambiguous because it can refer to the general concept of interactive command line, to the general concept of command line parameter parsing, or several libraries.

So, I plan to change the name of the library in the future. For this I want to ask you:

• What are the issues I will be facing by changing the name of an existing github project? (e.g., link name, repository name, ...)
• Any suggestion for a good name? A good name for me is ideally one autoexplicative and not already used by other well-known projects. If I don’t find an autoexplicative name, I will opt for some name with no meaning at all. To answer to any of these questions, you can use the github issue tracker or — better — my twitter account @DPallastrelli. Eventually I will do a twitter poll to decide for a good name.

Isn’t the snake_case naming convention better than the CamelCase for C++ code?

I don’t think it’s better (with CamelCase you have way more combination of identifiers available) but surely is the de-facto standard in modern C++ code. Unfortunately, the cli library started inside projects with that convention, and the first public releases had CamelCase APIs. Since I don’t want to break code already using the library just for a matter of “conventions”, I won’t change my code to snake_case.

But. If

1. The project will reach 1000 stars AND
2. Someone open an item in the github issue tracker asking me to change to snake_case AND
3. The item reach at least 800 stars then, I will change the case of the whole source code, breaking the API.

Other

• I’d like to publish a list of projects using the library, maybe on a page of this wiki or — in the future — in the library website (if the library will ever have one). So, I invite every user of the library who wants its project to be inserted int the list, to contact me via twitter at @DPallastrelli or through the github issue tracker.
• In general, to have updates about the library you should follow my twitter account @DPallastrelli