Program input parameters/options

[barcaroller]

Is there a recommended method of parsing program input parameters/options in
C++ programs?

The three methods that I know of are:

- C's getopt() and getopt_long()
- GNU C++ GetOpt class
- Boost.Program_options class library


There may be others.

 

[Mike Wahler]

Is there a recommended method of parsing program input parameters/options
in C++ programs?

I recommend using whichever works best for your needs.

The three methods that I know of are:

- C's getopt() and getopt_long()
- GNU C++ GetOpt class
- Boost.Program_options class library


There may be others.

Indeed, there is a virtually unlimited number of other
ways, since one can write his/her own parsing code.

-Mike

 

[Gianni Mariani]

Is there a recommended method of parsing program input parameters/options in
C++ programs?

The three methods that I know of are:

- C's getopt() and getopt_long()
- GNU C++ GetOpt class
- Boost.Program_options class library

You left out common c++'s "CommandOption".... (shameless plug).

CommandOption is a wrapper over getopt_long.

What I can find about the GetOpt class seems like it's just a call to
getopt_long.

The feature I like about CommandOption is that it is very extensible.
It allows you to create options anywhere in your application and it gets
parsed. The usage is created automatically (although it could be
better). It's simply a specify go type interface. I have not used
boost. It's relatively new.

From the little I have read, boost is a full application preferences
library as well. I think that overloads things a little too much and
for many small applications adds too much overhead. Austria C++ also
provides a "preferences" interface that is quite flexible - you should
look at that as well if you need a complete preferences utility.
Austria C++ uses XML to store preferences and it is able to merge
preferences from many places and allows for a hierarchy of preferences
(too much info here).

It's fairly trivial to give them all a go and see what you like best.
common c++ cmdoptions is a fairly small chunk of code that can be easily
separated from the rest of common c++.

 

[Robbie Hatley]

Is there a recommended method of parsing program input parameters/options in
C++ programs?

The three methods that I know of are:

- C's getopt() and getopt_long()
- GNU C++ GetOpt class
- Boost.Program_options class library

There may be others.

I just dump all of the command-line arguments into a std::vector<std::string>.
Then I can riffle through the vector looking for arguments that affect the
operation of the program, and set program variables and flags accordingly.

What do those other methods offer that my method doesn't?

 

[Gianni Mariani]

Robbie Hatley wrote:
....

I just dump all of the command-line arguments into a std::vector<std::string>.
Then I can riffle through the vector looking for arguments that affect the
operation of the program, and set program variables and flags accordingly.

What do those other methods offer that my method doesn't?

common c++ CommandOptions provides for:

a) Trivial extensibility - define and go
b) Auto usage creation
c) A simple level of automatic error checking


For example:

#include "cmdoptns.h"

ost::CommandOptionNoArg help_opt(
"help",
"?",
"Print help usage.",
false
);

ost::CommandOptionNoArg debug_opt(
"debug",
"d",
"Debug mode.",
false
);

static ost::CommandOptionArg exclude_opt(
"exclude",
"x",
"Exclude pattern",
false
);


int main( int argc, char** argv )
{
// parse the command line options
std::auto_ptr<ost::CommandOptionParse> args(
ost::makeCommandOptionParse(
argc, argv,
"....usage info....\n"
)
);

// If the user requested help
if ( help_opt.numSet ) {
std::cerr << args->printUsage();
return 1;
}

.... etc

}

 

[James Kanze]

You left out common c++'s "CommandOption".... (shameless plug).

And CommandLine/Option in the Gabi library.

CommandOption is a wrapper over getopt_long.

What I can find about the GetOpt class seems like it's just a call to
getopt_long.

Which still doesn't tell me much---I'm vaguely familiar with
getopt, but never used it much in C because is wasn't flexible
enough.

The feature I like about CommandOption is that it is very extensible.
It allows you to create options anywhere in your application and it gets
parsed.

Don't they all? Declaring options as static objects which
register themselves would seem a rather obvious idea.

The usage is created automatically (although it could be
better). It's simply a specify go type interface. I have not used
boost. It's relatively new.

Boost, or CommandOption?

I read the doc for Boost, and found that it did a little too
much for what I wanted. For the moment, I'm happy with my own
system, which has grown over a period of close to 15 years to
handle everything I happen to need. If you happen to need what
I need, or have needed in the past, it's probably a good
solution. If you need something else, it's probably not. This
is one case where I don't think that there is a universal
solution.

 

[James Kanze]

messagenews:[email protected]...

I just dump all of the command-line arguments into a
std::vector<std::string>. Then I can riffle through the
vector looking for arguments that affect the operation of the
program, and set program variables and flags accordingly.

What do those other methods offer that my method doesn't?

You don't have to riffle through the vector.

In the case of CommandLine/Option in Gabi lib:

-- Not requiring the option list to be centralized. Adding a
new option is as simple as declaring a static variable, in
the translation unit that uses it. You don't have to find
the global list and modify it, nor pass a vector or anything
into the module somehow as an argument.

-- Options are typed, with implicit conversions where it makes
sense (mainly for BooleanOption and NumericOption); given a
static variable:

BooleanOption b( 'b' ) ;

you can write simply:

if ( b ) {
// Option b was set...
} else {
// it wasn't...
}

To tell the truth, I'm not sure if the implicit conversions
are such a good idea, although they seem to work out OK for
boolean options. But simply declaring a BooleanOption, or a
NumericOption, and having all of the rest happen
automatically (including the conversion and verification of
the argument in NumericOption---there's also a
BoundNumericOption which allows you to specify bounds, and
get an error if the argument isn't within bounds), seems
like an advantage to me.

-- Common error handling. If the option requires an argument,
it requests one from the system, and is assured of getting
one. If the user enters an unrecognized option, there is an
error---you don't have to write code for this in each
application.

-- Support for various option conventions. In addition to the
classical "-x abc" (which becomes "/x abc" under
Windows---the system dependencies are handled by the
library), you can use long names, a la GNU, or the GNU
convention for arguments: "-xyz=abc". You can also choose
to treat some options in order, so that they only affect
files that follow them.

Finally, CommandLine appears as a standard STL sequence, with
the options and their arguments stripped out, to the user. So
you can use it directly as an argument for things like
MultipleFileInputStream (an istream which takes a list of
filenames in the constructor, and reads them one after the
other, reading from standard in if the list is empty, and only
returning EOF when all of the files have been read).

 

[Gianni Mariani]

James Kanze wrote:
....

Don't they all? Declaring options as static objects which
register themselves would seem a rather obvious idea.

You'd think so. Unfortunately many programmers at the time didn't know.

Boost, or CommandOption?

boost's command option parser thing.

I read the doc for Boost, and found that it did a little too
much for what I wanted.

I think I made the same point.

... For the moment, I'm happy with my own
system, which has grown over a period of close to 15 years to
handle everything I happen to need. If you happen to need what
I need, or have needed in the past, it's probably a good
solution. If you need something else, it's probably not. This
is one case where I don't think that there is a universal
solution.

CommandOption certainly does not cover all needs. It just does GNU
getopt in an object oriented way.

 

[Roland Pibinger]

Is there a recommended method of parsing program input parameters/options in
C++ programs?

This one seems to be nice: http://code.jellycan.com/simpleopt/