Command Line Interface (CLI) handling is a fairly common task for which there are no good C++ libraries. If you have just a handful of options, then the easiest route currently is to bite the bullet and write the parsing code by hand. Introducing an extra dependency on a CLI library that is still inconvenient to use does not sound like a good idea in this situation.

The XSD and XSD/e compilers that I currently work on each have a couple of hundred options and the new ones are added regularly. Hand-coding and maintaining the CLI parser in such situations quickly become a major burden. In my case I went ahead and implemented a CLI library which, while being quite convenient to use, has other drawback such as excessive compilation times due to the heavy use of templates (more on that later).

I feel it is now time for me to take another stab at this problem based on the experience I have gained. As an experiment I’ve decided to make the design process of this new CLI parser public in the hope of getting some feedback as I go along. This process will most likely take quite a bit longer than normal since I “design” much faster in my head than in my blog. But I am curious to see how such a collaborative effort might work. My goal is two-fold. First, I want to design and implement a truly elegant and convenient CLI parser and I hope your thoughts and suggestions will be valuable in achieving this. Second, I want to show how I (and perhaps you will join me) go about designing elegant and usable software. There is plenty of atrociously-designed code out there and we need any help and education we can get. (While this last part may sound like self-praising, a number of insightful people in the industry seem to think the software I have built in the past is quite good.)

The overall design principles are as follows. The CLI library will need to be cross-platform and liberally licensed (either LGPL or Apache 2.0) so that it can be used in a wide range of applications. Command line parsing is a peripheral functionality for most programs and adding any extra dependencies besides the CLI library itself will hinder its adoption. It will therefore rely only on standard C++98 (C++0x features, such as rvalue-references can be optionally supported). It may also be a good idea to strive for a header-only implementation.

The next couple of steps are as follows. First we need to get a better understanding of the problem(s) we are trying to solve as well as establish a terminology (is it a flag, option, argument?). Then I would like to examine the existing solutions and their drawbacks. For that I would like to consider the Program Options library from Boost as well as my previous attempt at the CLI library which is part of libcult (if you have any other candidates in mind, let me know in the comments). After these two steps we should be in a good position to think about what an ideal solution to our problem might look like.

So welcome on board and stick around. If you have any thoughts, feel free to add them as comments. Next week we will be getting an understanding of the problem domain as well as establishing the terminology.

This entry was posted on Monday, May 25th, 2009 at 10:25 am and is filed under CLI, Design, C++. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.