From: Sven M. Hallberg (pesco_at_[hidden])
Date: 2001-05-14 07:22:48
I'd like to discuss the following design question(s):
1. Should the option processor modify argc/argv, i.e. removing all options it
1a. Should options that generated an exception (due to a syntax error or
thelike) be removed also?
2. Should it even be passed argc/argv directly or maybe an iterator pair?
2a. If an iterator pair was used, how is the user supposed to get at the
Pass argc/argv. Remove all options recognized as such, regardless of
- argc/argv can be used after processing as if there had been no
- Resuming an interrupted processing run (due to an exception) is achieved
simply by calling the processor again on (the modified) argc/argv.
- Control over options is passed completely to the option processor,
information about the _exact_ command line args is lost.
- slim (^= simple) user code
- completely transparent option processing
- simple to resume
- limited flexibility
- Effects on intermangled non-option args are impossible.
Pass a pair of random access iterators. Move all options to the beginning
during processing. Preserve their order. Return the number of options on
success. In exceptions include the index of the option that generated the
- After successful processing, simply adding the number of options to the
first iterator yields the sequence of nonoptions.
- On error, the index provides access to the erroneous argument, as well as
the next argument, using which the processing can be resumed.
- The order of options intermangled with non-opts is lost.
- User code overhead (on success) is tiny.
- Error handling (including resume) is simple but flexible.
- Effects on intermangled non-option args are still impossible.
After examining the Situation I propose Idea B.
Summarizing the differences to Idea A:
- Complete transparency is lost. Generality to sequences is gained.
- Complete encapsulation of the process is lost. Flexibility is gained.
Loss of transparency means that one can no longer write the program as if
there was no option handling (except for the processing code itself). Looking
closer, however, reveals that the point after which the above effect appears
is just shifted down by a couple of code lines:
// make argc/argv look more sequence-like
typedef char* Arg_iter;
Arg_iter arg_begin = argv+1;
Arg_iter arg_end = argv+argc;
// [... processing code omitted ...]
arg_begin += optcount; // remove all opts from the arg sequence
After that the iterators arg_begin and arg_end again denote the sequence of
non-option arguments as if there had never been such a thing as command line
Loss of complete encapsulation means that one can no longer just pass the
arguments to a magical gadget called option_processor and forget the issue.
One must remember what the argument sequence is and what exactly it contains
before _and after_ invoking the processor. Of course this is a price, but
merely one that belongs in the RTFM-department. It can be expected of a
programmer to know what command line options are. :)
The last point to ration out is the one common to Idea A and B: the loss of
information about non-opts intermangled with the options. I argue that there
is _no_ need for that information, because the things that those non-opts are
intermangled with in this scenario are not to be considered options.
My definition of an option is:
An optional setting which causes a certain modification to a program's
Options should apply to the program's behaviour, not command line arguments.
Attaching properties to a program's arguments is an area entirely different
from option handling.
-- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk