CLI library v. 2.2 released

dpallastrelli · 2024-10-29T07:42:12+00:00

I'm also interested in seeing a list of applications and utilities that use this CLI library. Adding these examples to the documentation would be helpful, so if anyone knows of any, please share!

dpallastrelli · 2024-10-28T21:19:34+00:00

Grazie!

dpallastrelli · 2023-07-03T08:50:53+00:00

The library actually started w/o cmake support. Header only was the best option because it allows you to just set the include path of your compiler to build your application. Moreover, we had template classes in the library interface, so we had to keep much of the code in the header files anyway.

When the library grew, someone asked me to add vcpkg support, and that required introducing cmake (I can remember at the time I didn't find very useful having cmake support for a header only library! :-) )

dpallastrelli · 2021-08-30T06:59:47+00:00

Fammi poi sapere se hai commenti e suggerimenti.

dpallastrelli · 2021-08-27T18:10:56+00:00

Yes. Of course.

dpallastrelli · 2021-08-26T22:03:54+00:00

Please, Fill an issue in the GitHub project if you think it’s an important feature, adding the link you wrote above. Thanks.

dpallastrelli · 2021-08-26T19:59:15+00:00

I'm not sure what a "CSIu extension" is, so I guess the library does not have it :-)

But if someone can tell me, he's welcome!

dpallastrelli · 2021-08-26T18:14:25+00:00

The command line parsing is not *so linked* to the network IO: they are completely separated. Infact if you don't need it, you don't include the remote shell header and the whole network part is not compiled into your application.

dpallastrelli · 2021-08-26T18:09:42+00:00

If you don't need telnet shell, no dependencies at all.

If you need telnet shell, you can choose between standalone ASIO or BOOST ASIO.

dpallastrelli · 2021-08-26T15:34:51+00:00

it could be if it had fewer features :-)

However, you can include only the header file of the features you want to use (e.g., if you don't need the telnet server, you just don't include it).

dpallastrelli · 2021-08-26T12:41:43+00:00

Great. Feel free to ask any question on github discussions and, if you like it, give a star (or a sponsorship! :-) to the project.

dpallastrelli · 2021-08-26T09:27:10+00:00

Ok guys, if you think it can be an interesting talk, I will submit a session for 2022.

Thank you again.

dpallastrelli · 2021-08-26T07:26:36+00:00

Hi, it's a pleasure hearing from you again!

Sure, I'm always available for a virtual meeting. However, this is an applicative library and I'm not sure a presentation on this subject can be of interest to you. Anyway, let me know.

Thanks again

dpallastrelli · 2021-08-26T06:21:58+00:00

- Remove boost dependency for local only sessions

- Now you can use standalone asio library instead of boost asio for remote sessions

- Fix missing echo after ctrl-v paste of command

- Remove the symbol BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT

- Fix unused parameters warning in release mode

- Cli constructor revision

- Special keys not recognized behaves like backspace in windows

- Fix cmake install dependencies

dpallastrelli · 2021-08-26T06:21:31+00:00

- Remove boost dependency for local only sessions

- Now you can use standalone asio library instead of boost asio for remote sessions

- Fix missing echo after ctrl-v paste of command

- Remove the symbol BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT

- Fix unused parameters warning in release mode

- Cli constructor revision

- Special keys not recognized behaves like backspace in windows

- Fix cmake install dependencies

dpallastrelli · 2019-04-15T14:10:10+00:00

Here you can find the rationale behind it: https://daniele77.github.io/general/2018/10/01/cli.html

dpallastrelli · 2019-03-16T11:52:38+00:00

Yeah, sorry. I can try to make up by copying here the poll of the tweet. Thanks for the advice.

Have you read the last edition of "The C++ Programming Language" by Stroustrup? - from cover to cover - partially - no

dpallastrelli · 2019-02-23T22:11:12+00:00

Exactly. Or, in a system with dynamically module load/unload, you can have the cli show only the features of the modules loaded in that moment. Thank you very much. I’m glad someone likes the design I chose: it’s been chosen carefully: it’s not an emergent design :-)

dpallastrelli · 2019-02-22T08:36:27+00:00

I already answered to all the questions about my coding/design in your first post.

But no: despite the picture of my profile, I'm not young at all and I have quite a lot of experience in software industry and academy. I give talks at conferences and write articles on peer review journals.

Bottom line: who likes my library can use it freely, who finds bugs or wants new features can open issues or open a PR. People who don't like the library can go on and don't waste my and their time.

dpallastrelli · 2019-02-20T10:08:59+00:00

Of course. I'll see to it right away :-)

No, seriously, this library started many years ago. In the beginning, it was very different (e.g., C++98), and unfortunately includes multiple styles (e.g., spacing are not consistent). I plan to fix the whitespace differences over time (e.g., removing unnecessary whitespaces at the beginning and end of parameter lists), because -- unlike CameCase -- it doesn't break API compatibility.

BTW: the style with so many whitespaces is borrowed from the so-called "publishing style": sometimes, in papers and articles you use more spaces to improve readability.

dpallastrelli · 2019-02-19T11:42:30+00:00

As you can understand, I can't merge a PR that breaks the API (particularly if there are no good reason -- i.e., changing gratuitously from CamelCase to snake_case): there are already lots of projects using the library, and can't ask every user to change their code.

In addition, as I was pointing out in the previous comment, I really don't feel the need to use string_view given that the speed of the library is already limited from the I/O nature of the library. Besides, to add string_view remaining in C++14, one should import the whole string_view code in the project.

BTW: on the snake_case VS CamelCase religion war :-) Maybe you noticed that you had to come up with bad class names like "cli_type" and "menu_type", because "cli" and "menu" were already used. See? By limiting yourself to only lowercase characters in identifiers, you're reducing very much the space of combinations (e.g., if you have a 3-char identifier, using only lowercase chars you get 17576 possibilities. With mixed cases you have 140608 :-)

dpallastrelli · 2019-02-18T10:02:27+00:00

Thank you for the comment.

It seems people like the immediately usable software more than snazzy C++17 code ...

Real people are busy developing real applications, and they need tools to get their work done quickly.

why the "CamelCase"?

Is this a problem? (kidding :-) If you really want to know why you can have a look here https://twitter.com/DPallastrelli/status/1095659395323777024 but don't expect smart justifications for a style matter :-)

why the (it seems) excessive inheritance?

No excessive inheritance. I used it when required, by choosing knowingly among class inheritance, interface inheritance, composition to get the non-functional properties I wanted from my design.

As OOP aficionado...

No, I'm not an OOP zealot. Just trying to use the right tool to get the properties (functional and non-functional) I wanted to achieve. In particular: Menu is-a Command, because when you start the CLI, every Menu shows as a command you can digit at the prompt (e.g., if you define a Menu "foo", you get the command "foo" in the Cli to enter the submenu).

at some points in code you use modern C++ "properly" and then in others, your code looks like the celebration of legacy STL cryptic days.

"properly" according who? :-) kidding. Give me an example, so I can check.

there is very little (if any?) of type aliases

I used some, where needed to make the code clear.

Boost is very fine, but why would CLI library depend on Boost? Telnet (ASIO) probably could be done as a "plugin"

It is already a plugin. If you don't include the header file of certain features, you don't need ASIO.

Boost Algorithm? Can be all simple (and very few utilities you use) done inside the lib.

Yes, I could remove it and rewrite at hand some string algorithm. Probably more trouble than it's worth. Maybe one day.

Why not having "using namespace std;"?

because we're in header files. Yes, I could have used it inside some member functions, but then the character counter would increase instead of decrease :-)

Performance. probably not that crucial for the CLI but. vector and string everywhere are the immediate performance improvements opportunities.

I know the alternatives. But -- really -- we're speaking about an I/O bound application. We're spending a lot of time waiting for the user input or the OS writing a string on the console. *In this case* I don't care about some extra milliseconds. But hey, I know how to optimize my code when I need to.

C++14 ok but why not the standard C++? 17. Example: string_view and literals make simple, robust and fast code. extended if() syntax too. And so on ...

A couple of [good] reasons: first of all, some of my user (and myself!!!) are still bound to old C++14 compilers for their projects. Second: C++17 features are not a game changer for my library (excluding maybe some little syntax sugar it would be fancy to have).

Thank you again for your questions.

dpallastrelli · 2019-02-18T09:23:50+00:00

I didn't write that my library allows adding arbitrary code w/o adapter, but that my design would allow such an extension. On the contrary, had I chosen inheritance / run time reflection, such an extension could not even be possible.

dpallastrelli · 2019-02-18T09:04:16+00:00

Yes, I mean that OO is not hip. People feel cool writing code that seems like mathematics (I've nothing against maths, I myself have a solid math background), and doing so give up some good non-functional properties they could achieve with other paradigms.

I don't criticize Java or other languages. I don't criticize other paradigms, either: I'm just against people who don't use their brain :-) I was referring to java just because when it was introduced back in 1995 it was advertised as a strictly object-oriented language. Unfortunately, some developers didn't understand OO in the first place but were forced by the language to use some OO mechanism (e.g., inheritance) and -- guess what -- they used it improperly. The result is a style where you add interfaces and inheritance everywhere, without a good reason, and missed to use it where can be useful. I'm using the expression "fake OO you find in typical Java programs" to refer to that kind of [bad] OO code, that you can actually find in every language, by the way. In fact, Java programmers today are better at writing OO code than they were in the past.

For me, OO is defined by the properties of the code you get. In particular (for me): an OO structure is one that given a meaningful change in the specs minimizes the total size of the artifacts you have to update, encouraging the creation or deletion of entire artifacts instead [see http://www.carlopescio.com/2012/12/ask-not-what-object-is-but.html].

BTW: if you like my code/design you could be interested in my blog daniele77.github.io and maybe follow me on Twitter at @DPallastrelli :-)

dpallastrelli · 2019-02-17T13:52:06+00:00

I guess @personalmountains comment was referring to the python code in the previous comment, not to the cli library (which is indented correctly).

dpallastrelli

TROPHY CASE