# Templatized C++ Command Line Parser Manual

### Michael E Smoot

Copyright © 2003,2004,2005,2006,2009,2011 Michael E. Smoot

## Chapter 1. Basic Usage

## Overview

TCLAP has a few key classes to be aware of. The first is the `CmdLine` (command line) class. This class parses the command line passed to it according to the arguments that it contains. Arguments are separate objects that are added to the `CmdLine` object one at a time. The six argument classes are: `ValueArg`, `UnlabeledValueArg`, `SwitchArg`, `MultiSwitchArg`, `MultiArg` and `UnlabeledMultiArg`. These classes are templatized, which means they can be defined to parse a value of any type. Once you add the arguments to the `CmdLine` object, it parses the command line and assigns the data it finds to the specific argument objects it contains. Your program accesses the values parsed by calls to the `getValue()` methods of the argument objects.

## Example

Here is a simple example ...

    #include <string>
    #include <iostream>
    #include <algorithm>
    #include <tclap/CmdLine.h>

    int main(int argc, char** argv)
    {

    	// Wrap everything in a try block.  Do this every time,
    	// because exceptions will be thrown for problems.
    	try {

    	// Define the command line object, and insert a message
    	// that describes the program. The "Command description message"
    	// is printed last in the help text. The second argument is the
    	// delimiter (usually space) and the last one is the version number.
    	// The CmdLine object parses the argv array based on the Arg objects
    	// that it contains.
    	TCLAP::CmdLine cmd("Command description message", ' ', "0.9");

    	// Define a value argument and add it to the command line.
    	// A value arg defines a flag and a type of value that it expects,
    	// such as "-n Bishop".
    	TCLAP::ValueArg<std::string> nameArg("n","name","Name to print",true,"homer","string");

    	// Add the argument nameArg to the CmdLine object. The CmdLine object
    	// uses this Arg to parse the command line.
    	cmd.add( nameArg );

    	// Define a switch and add it to the command line.
    	// A switch arg is a boolean argument and only defines a flag that
    	// indicates true or false.  In this example the SwitchArg adds itself
    	// to the CmdLine object as part of the constructor.  This eliminates
    	// the need to call the cmd.add() method.  All args have support in
    	// their constructors to add themselves directly to the CmdLine object.
    	// It doesn't matter which idiom you choose, they accomplish the same thing.
    	TCLAP::SwitchArg reverseSwitch("r","reverse","Print name backwards", cmd, false);

    	// Parse the argv array.
    	cmd.parse( argc, argv );

    	// Get the value parsed by each arg.
    	std::string name = nameArg.getValue();
    	bool reverseName = reverseSwitch.getValue();

    	// Do what you intend.
    	if ( reverseName )
    	{
    		std::reverse(name.begin(),name.end());
    		std::cout << "My name (spelled backwards) is: " << name << std::endl;
    	}
    	else
    		std::cout << "My name is: " << name << std::endl;

    	} catch (TCLAP::ArgException &e)  // catch any exceptions
    	{ std::cerr << "error: " << e.error() << " for arg " << e.argId() << std::endl; }
    }

The output should look like:

    % test1 -n mike
    My name is: mike

    % test1 -n mike -r
    My name (spelled backwards) is: ekim

    % test1 -r -n mike
    My name (spelled backwards) is: ekim

    % test1 -r
    PARSE ERROR:
                 One or more required arguments missing!

    Brief USAGE:
       test1  [-r] -n <string> [--] [-v] [-h]

    For complete USAGE and HELP type:
       test1 --help

    % test1 --help

    USAGE:

       test1  [-r] -n <string> [--] [-v] [-h]

    Where:

       -r,  --reverse
         Print name backwards

       -n <string>  --name <string>
         (required)  (value required)  Name to print

       --,  --ignore_rest
         Ignores the rest of the labeled arguments following this flag.

       -v,  --version
         Displays version information and exits.

       -h,  --help
         Displays usage information and exits.

       Command description message

### Library Properties

This example shows a number of different properties of the library...

- Arguments can appear in any order (...mostly, more on this later).
- The `help`, `version` and `--``SwitchArg`s are specified automatically. Using either the `-h` or `--help` flag will cause the USAGE message to be displayed, `-v` or `--version` will cause any version information to be displayed, and `--` or `--ignore_rest` will cause the remaining labeled arguments to be ignored. These switches are included by default on every command line. You can disable this functionality if desired (although we don't recommend it). How we generate the behavior behind these flags is described later.
- If there is an error parsing the command line (e.g. a required argument isn't provided), the program exits and displays a brief USAGE and an error message.
- The program name is assumed to always be argv[0], so it isn't specified directly.
- A value delimiter character can be specified. This means that if you prefer arguments of the style `-s=asdf` instead of `-s asdf`, you can do so.
- Always wrap everything in a try block that catches ArgExceptions! Any problems found in constructing the `CmdLine`, constructing the `Arg`s, or parsing the command line will throw an `ArgException`.

### Common Argument Properties

Arguments, whatever their type, have a few common properties. These properties are set in the constructors of the arguments.

- First is the flag or the character preceded by a dash(-) that signals the beginning of the argument on the command line.
- Arguments also have names, which can also be used as an alternative flag on the command line, this time preceded by two dashes (--) [like the familiar `getopt_long()`].
- Next is the description of the argument. This is a short description of the argument displayed in the help/usage message when needed.
- The following parameters in the constructors vary depending on the type of argument. Some possible values include:
  - A boolean value indicating whether the Arg is required or not.
  - A default value.
  - A description of the type of value expected.
  - A constraint on the value expected.
  - The CmdLine instance that the Arg should be added to.
  - A Visitor.
- See the API Documentation for more detail.

## Compiling

TCLAP is implemented entirely in header files which means you only need to include CmdLine.h to use the library.

            #include <tclap/CmdLine.h>

You'll need to make sure that your compiler can see the header files. If you do the usual "make install" then your compiler should see the files by default. Alternatively, you can use the -I complier argument to specify the exact location of the libraries.

            c++ -o my_program -I /some/place/tclap-1.X/include my_program.cpp

Where /some/place/tclap-1.X is the place you have unpacked the distribution.

Finally, if you want to include TCLAP as part of your software (which is perfectly OK, even encouraged) then simply copy the contents of /some/place/tclap-1.X/include (the tclap directory and all of the header files it contains) into your include directory. The necessary m4 macros for proper configuration are included in the config directory.

TCLAP was developed on Linux and MacOSX systems. It is also known to work on Windows, Sun and Alpha platforms. We've made every effort to keep the library compliant with the ANSI C++ standard so if your compiler meets the standard, then this library should work for you. Please let us know if this is not the case!

### Windows Note

As we understand things, Visual C++ does not have the file `config.h` which is used to make platform specific definitions. In this situation, we assume that you have access to `sstream`. Our understanding is that this should not be a problem for VC++ 7.x. However, if this is not the case and you need to use `strstream`, then simply tell your compiler to define the variable `HAVE_STRSTREAM` and undefine `HAVE_SSTREAM` That should work. We think. Alternatively, just edit the files `ValueArg.h` and `MultiArg.h`.

### Random Note

If your compiler doesn't support the `using` syntax used in `UnlabeledValueArg` and `UnlabeledMultiArg` to support two stage name lookup, then you have two options. Either comment out the statements if you don't need two stage name lookup, or do a bunch of search and replace and use the `this` pointer syntax: e.g. `this->_ignoreable` instead of just `_ignorable` (do this for each variable or method referenced by `using`).

## Chapter 2. Fundamental Classes

## `CmdLine`

The `CmdLine` class contains the arguments that define the command line and manages the parsing of the command line. The `CmdLine` doesn't parse the command line itself it only manages the parsing. The actual parsing of individual arguments occurs within the arguments themselves. The `CmdLine` keeps track of of the required arguments, relationships between arguments, and output generation.

## `SwitchArg`

`SwitchArg`s are what the name implies: simple, on/off, boolean switches. Use `SwitchArg`s anytime you want to turn some sort of system property on or off. `SwitchArg`s don't parse a value. They return `TRUE` or `FALSE`, depending on whether the switch has been found on the command line and what the default value was defined as.

## `ValueArg`

`ValueArg`s are arguments that read a value of some type from the command line. Any time you need a file name, a number, etc. use a `ValueArg` or one of its variants. All `ValueArg`s are templatized and will attempt to parse the string its flag matches on the command line as the type it is specified as. `ValueArg<int>` will attempt to parse an int, `ValueArg<float>` will attempt to parse a float, etc. If `operator>>` for the specified type doesn't recognize the string on the command line as its defined type, then an exception will be thrown.

## `MultiArg`

A `MultiArg` is a `ValueArg` that can be specified more than once on a command line and instead of returning a single value, returns a `vector` of values.

Imagine a compiler that allows you to specify multiple directories to search for libraries...

                    % fooCompiler -L /dir/num1 -L /dir/num2 file.foo

Exceptions will occur if you try to do this with a `ValueArg` or a `SwitchArg`. In situations like this, you will want to use a `MultiArg`. A `MultiArg` is essentially a `ValueArg` that appends any value that it matches and parses onto a vector of values. When the `getValue()` method is called, a vector of values, instead of a single value is returned. A `MultiArg` is declared much like a `ValueArg`:

                    MultiArg<int> itest("i", "intTest", "multi int test", false,"int" );
                    cmd.add( itest );

Note that `MultiArg`s can be added to the `CmdLine` in any order (unlike UnlabeledMultiArg).

## `MultiSwitchArg`

A `MultiSwitchArg` is a `SwitchArg` that can be specified more than once on a command line. This can be useful when command lines are constructed automatically from within other applications or when a switch occurring more than once indicates a value (-V means a little verbose -V -V -V means a lot verbose), You can use a `MultiSwitchArg`. The call to `getValue()` for a `MultiSwitchArg` returns the number (int) of times the switch has been found on the command line in addition to the default value. Here is an example using the default initial value of 0:

    	MultiSwitchArg quiet("q","quiet","Reduce the volume of output");
    	cmd.add( quiet );

Alternatively, you can specify your own initial value:

    	MultiSwitchArg quiet("q","quiet","Reduce the volume of output",5);
    	cmd.add( quiet );

## `UnlabeledValueArg`

An `UnlabeledValueArg` is a `ValueArg` that is not identified by a flag on the command line. Instead `UnlabeledValueArg`s are identified by their position in the argv array.

To this point all of our arguments have had labels (flags) identifying them on the command line, but there are some situations where flags are burdensome and not worth the effort. One example might be if you want to implement a magical command we'll call copy. All copy does is copy the file specified in the first argument to the file specified in the second argument. We can do this using `UnlabeledValueArg`s which are pretty much just `ValueArg`s without the flag specified, which tells the `CmdLine` object to treat them accordingly. The code would look like this:

                    UnlabeledValueArg<float>  nolabel( "name", "unlabeled test", 3.14,
                                                      "nameString"  );
                    cmd.add( nolabel );

Everything else is handled identically to what is seen above. The only difference to be aware of, and this is important: the order that UnlabeledValueArgs are added to the `CmdLine` is the order that they will be parsed!!!! This is not the case for normal `SwitchArg`s and `ValueArg`s. What happens internally is the first argument that the `CmdLine` doesn't recognize is assumed to be the first `UnlabeledValueArg` and parses it as such. Note that you are allowed to intersperse labeled args (SwitchArgs and ValueArgs) in between `UnlabeledValueArgs` (either on the command line or in the declaration), but the `UnlabeledValueArgs` will still be parsed in the order they are added. Just remember that order is important for unlabeled arguments.

## `UnlabeledMultiArg`

An `UnlabeledMultiArg` is an `UnlabeledValueArg` that allows more than one value to be specified. Only one `UnlabeledMultiArg` can be specified per command line. The `UnlabeledMultiArg` simply reads the remaining values from argv up until -- or the end of the array is reached.

Say you want a strange command that searches each file specified for a given string (let's call it grep), but you don't want to have to type in all of the file names or write a script to do it for you. Say,

                    % grep pattern *.txt

First remember that the * is handled by the shell and expanded accordingly, so what the program grep sees is really something like:

                    % grep pattern file1.txt file2.txt fileZ.txt

To handle situations where multiple, unlabeled arguments are needed, we provide the `UnlabeledMultiArg`. `UnlabeledMultiArg`s are declared much like everything else, but with only a description of the arguments. By default, if an `UnlabeledMultiArg` is specified, then at least one is required to be present or an exception will be thrown. The most important thing to remember is, that like `UnlabeledValueArg`s: order matters! In fact, an UnlabeledMultiArg must be the last argument added to the CmdLine!. Here is what a declaration looks like:

                    //
                    // UnlabeledMultiArg must be the LAST argument added!
                    //
                    UnlabeledMultiArg<string> multi("file names");
                    cmd.add( multi );
                    cmd.parse(argc, argv);

                    vector<string>  fileNames = multi.getValue();

You must only ever specify one (1) `UnlabeledMultiArg`. One `UnlabeledMultiArg` will read every unlabeled Arg that wasn't already processed by a `UnlabeledValueArg` into a `vector` of type T. Any `UnlabeledValueArg` or other `UnlabeledMultiArg` specified after the first `UnlabeledMultiArg` will be ignored, and if they are required, exceptions will be thrown. When you call the `getValue()` method of the `UnlabeledValueArg` argument, a `vector` will be returned. If you can imagine a situation where there will be multiple args of multiple types (stings, ints, floats, etc.) then just declare the `UnlabeledMultiArg` as type `string` and parse the different values yourself or use several `UnlabeledValueArg`s.

## Chapter 3. Complications

Naturally, what we have seen to this point doesn't satisfy all of our needs.

## I want to combine multiple switches into one argument...

Multiple `SwitchArg`s can be combined into a single argument on the command line. If you have switches -a, -b and -c it is valid to do either:

                    % command -a -b -c

or

                    % command -abc

or

                    % command -ba -c

This is to make this library more in line with the POSIX and GNU standards (as I understand them).

## I want one argument or the other, but not both...

Suppose you have a command that must read input from one of two possible locations, either a local file or a URL. The command must read something, so one argument is required, but not both, yet neither argument is strictly necessary by itself. This is called "exclusive or" or "XOR". To accommodate this situation, there is now an option to add two or more `Arg`s to a `CmdLine` that are exclusively or'd with one another: `xorAdd()`. This means that exactly one of the `Arg`s must be set and no more.

`xorAdd()` comes in two flavors, either `xorAdd(Arg& a, Arg& b)` to add just two `Arg`s to be xor'd and `xorAdd( vector<Arg*> xorList )` to add more than two `Arg`s.

            ValueArg<string>  fileArg("f","file","File name to read",true,"/dev/null", "filename");
            ValueArg<string>  urlArg("u","url","URL to load",true, "http://example.com", "URL");

            cmd.xorAdd( fileArg, urlArg );
            cmd.parse(argc, argv);

Once one `Arg` in the xor list is matched on the `CmdLine` then the others in the xor list will be marked as set. The question then, is how to determine which of the `Arg`s has been set? This is accomplished by calling the isSet() method for each `Arg`. If the `Arg` has been matched on the command line, the `isSet()` will return `TRUE`, whereas if the `Arg` has been set as a result of matching the other `Arg` that was xor'd `isSet()` will return `FALSE`. (Of course, if the `Arg` was not xor'd and wasn't matched, it will also return `FALSE`.)

            if ( fileArg.isSet() )
                    readFile( fileArg.getValue() );
            else if ( urlArg.isSet() )
                    readURL( urlArg.getValue() );
            else
                    // Should never get here because TCLAP will note that one of the
                    // required args above has not been set.
                    throw("Very bad things...");

It is helpful to note that `Arg`s of any type can be xor'd together. This means that you can xor a `SwitchArg` with a `ValueArg`. This is helpful in situations where one of several options is necessary and one of the options requires additional information.

            SwitchArg  stdinArg("s", "stdin", "Read from STDIN", false);
            ValueArg<string>  fileArg("f","file","File name to read",true,"/dev/null", "filename");
            ValueArg<string>  urlArg("u","url","URL to load",true, "http://example.com", "URL");

            vector<Arg*>  xorlist;
            xorlist.push_back(&stdinArg);
            xorlist.push_back(&fileArg);
            xorlist.push_back(&urlArg);

            cmd.xorAdd( xorlist );

## I have more arguments than single flags make sense for...

Some commands have so many options that single flags no longer map sensibly to the available options. In this case, it is desirable to specify `Arg`s using only long options. This one is easy to accomplish, just make the flag value blank in the `Arg` constructor. This will tell the `Arg` that only the long option should be matched and will force users to specify the long option on the command line. The help output is updated accordingly.

            ValueArg<string>  fileArg("","file","File name",true,"homer","filename");

            SwitchArg  caseSwitch("","upperCase","Print in upper case",false);

## I want to constrain the values allowed for a particular argument...

Interface Change!!! Sorry folks, but we've changed the interface since version 1.0.X for constraining `Arg`s. Constraints are now hidden behind the `Constraint` interface. To constrain an `Arg` simply implement the interface and specify the new class in the constructor as before.

You can still constrain `Arg`s based on a list of values. Instead of adding a `vector` of allowed values to the `Arg` directly, create a `ValuesConstraint` object with a `vector` of values and add that to the `Arg`. The `Arg` constructors have been modified accordingly.

When the value for the `Arg` is parsed, it is checked against the list of values specified in the `ValuesConstraint`. If the value is in the list then it is accepted. If not, then an exception is thrown. Here is a simple example:

    		vector<string> allowed;
    		allowed.push_back("homer");
    		allowed.push_back("marge");
    		allowed.push_back("bart");
    		allowed.push_back("lisa");
    		allowed.push_back("maggie");
    		ValuesConstraint<string> allowedVals( allowed );

    		ValueArg<string> nameArg("n","name","Name to print",true,"homer",&allowedVals);
    		cmd.add( nameArg );

When a `ValuesConstraint` is specified, instead of a type description being specified in the `Arg`, a type description is created by concatenating the values in the allowed list using operator<< for the specified type. The help/usage for the `Arg` therefore lists the allowable values. Because of this, you might want to keep the list relatively small, however there is no limit on this.

Obviously, a list of allowed values isn't always the best way to constrain things. For instance, one might wish to allow only integers greater than 0. In this case, simply create a class that implements the `Constraint<int>` interface and checks whether the value parsed is greater than 0 (done in the `check()` method) and create your `Arg` with your new `Constraint`.

## I want the Args to add themselves to the CmdLine...

New constructors have been added for each `Arg` that take a `CmdLine` object as an argument. Each `Arg` then `add`s itself to the `CmdLine` object. There is no difference in how the `Arg` is handled between this method and calling the `add()` method directly. At the moment, there is no way to do an `xorAdd()` from the constructor. Here is an example:

            // Create the command line.
            CmdLine cmd("this is a message", '=', "0.99" );

            // Note that the following args take the "cmd" object as arguments.
            SwitchArg btest("B","existTestB", "exist Test B", cmd, false );

            ValueArg<string> stest("s", "stringTest", "string test", true, "homer",
                                                   "string", cmd );

            UnlabeledValueArg<string> utest("unTest1","unlabeled test one",
                                                            "default","string", cmd );

            // NO add() calls!

            // Parse the command line.
            cmd.parse(argc,argv);

## I want different output than what is provided...

It is straightforward to change the output generated by TCLAP. Either subclass the `StdOutput` class and re-implement the methods you choose, or write your own class that implements the `CmdLineOutput` interface. Once you have done this, then use the `CmdLine` `setOutput` method to tell the `CmdLine` to use your new output class. Here is a simple example:

    class MyOutput : public StdOutput
    {
    	public:
    		virtual void failure(CmdLineInterface& c, ArgException& e)
    		{
    			cerr << "My special failure message for: " << endl
    				 << e.what() << endl;
    			exit(1);
    		}

    		virtual void usage(CmdLineInterface& c)
    		{
    			cout << "my usage message:" << endl;
    			list<Arg*> args = c.getArgList();
    			for (ArgListIterator it = args.begin(); it != args.end(); it++)
    				cout << (*it)->longID()
    					 << "  (" << (*it)->getDescription() << ")" << endl;
    		}

    		virtual void version(CmdLineInterface& c)
    		{
    			cout << "my version message: 0.1" << endl;
    		}
    };

    int main(int argc, char** argv)
    {
    		CmdLine cmd("this is a message", ' ', "0.99" );

    		// set the output
    		MyOutput my;
    		cmd.setOutput( &my );

    		// proceed normally ...

See `test4.cpp` in the examples directory for the full example. NOTE: if you supply your own Output object, we will not delete it in the `CmdLine` destructor. This could lead to a (very small) memory leak if you don't take care of the object yourself. Also note that the `failure` method is now responsible for exiting the application (assuming that is the desired behavior).

## I don't want the --help and --version switches to be created automatically...

Help and version information is useful for nearly all command line applications and as such we generate flags that provide those options automatically. However, there are situations when these flags are undesirable. For these cases we've added we've added a forth parameter to the `CmdLine` constructor. Making this boolean parameter false will disable automatic help and version generation.

    		CmdLine cmd("this is a message", ' ', "0.99", false );

## I want to ignore certain arguments...

The `--` flag is automatically included in the `CmdLine`. As (almost) per POSIX and GNU standards, any argument specified after the `--` flag is ignored. Almost because if an `UnlabeledValueArg` that has not been set or an `UnlabeledMultiArg` has been specified, by default we will assign any arguments beyond the `--` to the those arguments as per the rules above. This is primarily useful if you want to pass in arguments with a dash as the first character of the argument. It should be noted that even if the `--` flag is passed on the command line, the `CmdLine` will still test to make sure all of the required arguments are present.

Of course, this isn't how POSIX/GNU handle things, they explicitly ignore arguments after the `--`. To accommodate this, we can make both `UnlabeledValueArg`s and `UnlabeledMultiArg`s ignoreable in their constructors. See the API Documentation for details.

## I want to read hex integers as arguments...

Sometimes it's desirable to read integers formatted in decimal, hexadecimal, and octal format. This is now possible by #defining the `TCLAP_SETBASE_ZERO` directive. Simply define this directive in your code and integer arguments will be parsed in each base.

    #define TCLAP_SETBASE_ZERO 1

    #include "tclap/CmdLine.h"
    #include <iostream>

    using namespace TCLAP;
    using namespace std;

    int main(int argc, char** argv)
    {

    	try {

    	CmdLine cmd("this is a message", ' ', "0.99" );

    	ValueArg<int> itest("i", "intTest", "integer test", true, 5, "int");
    	cmd.add( itest );

    	//
    	// Parse the command line.
    	//
    	cmd.parse(argc,argv);

    	//
    	// Set variables
    	//
    	int _intTest = itest.getValue();
    	cout << "found int: " << _intTest << endl;

    	} catch ( ArgException& e )
    	{ cout << "ERROR: " << e.error() << " " << e.argId() << endl; }
    }

The reason that this behavior is not the default behavior for TCLAP is that the use of `setbase(0)` appears to be something of a side effect and is not necessarily how `setbase()` is meant to be used. So while we're making this functionality available, we're not turning it on by default for fear of bad things happening in different compilers. If you know otherwise, please let us know.

## I want to use different types...

The usual C++ types (int, long, bool, etc.) are supported by TCLAP out of the box. As long as operator>> and operator<< are supported, other types should work fine too, you'll just need to specify the `ArgTraits` which tells TCLAP how you expect the type to be handled.

For example, assume that you'd like to read one argument on the command line in as a `std::pair` object. All you'll need to do is tell TCLAP whether to treat `std::pair` as a String or Value. StringLike means to treat the string on the command line as a string and use it directly, whereas ValueLike means that a value object should be extracted from the string using operator>>. For `std::pair` we'll choose ValueLike. To accomplish this, add the following declaration to your file:

      template<class T, class U>
      struct ArgTraits<std::pair<T, U>> {
        typedef ValueLike ValueCategory;
      };

For complete examples see the files `test11.cpp` and `test12.cpp` in the examples directory.

## I want to use Windows-style flags like "/x" and "/y"...

It is traditional in Posix environments that the "-" and "--" strings are used to signify the beginning of argument flags and long argument names. However, other environments, namely Windows, use different strings. TCLAP allows you to control which strings are used with `#define` directives. This allows you to use different strings based on your operating environment. Here is an example:

    //
    // This illustrates how to change the flag and name start strings for
    // Windows, otherwise the defaults are used.
    //
    // Note that these defines need to happen *before* tclap is included!
    //
    #ifdef WINDOWS
    #define TCLAP_NAMESTARTSTRING "~~"
    #define TCLAP_FLAGSTARTSTRING "/"
    #endif

    #include "tclap/CmdLine.h"

    using namespace TCLAP;
    using namespace std;

    int main(int argc, char** argv)
    {
    	// Everything else is identical!
    	...

## Chapter 4. Notes

Like all good rules, there are many exceptions....

## Type Descriptions

Ideally this library would use RTTI to return a human readable name of the type declared for a particular argument. Unfortunately, at least for g++, the names returned aren't particularly useful.

## Visitors

Disclaimer: Almost no one will have any use for `Visitor`s, they were added to provide special handling for default arguments. Nothing that `Visitor`s do couldn't be accomplished by the user after the command line has been parsed. If you're still interested, keep reading...

Some of you may be wondering how we get the `--help`, `--version` and `--` arguments to do their thing without mucking up the `CmdLine` code with lots of if statements and type checking. This is accomplished by using a variation on the Visitor Pattern. Actually, it may not be a Visitor Pattern at all, but that's what inspired me.

If we want some argument to do some sort of special handling, besides simply parsing a value, then we add a `Visitor` pointer to the `Arg`. More specifically, we add a subclass of the `Visitor` class. Once the argument has been successfully parsed, the `Visitor` for that argument is called. Any data that needs to be operated on is declared in the `Visitor` constructor and then operated on in the `visit()` method. A `Visitor` is added to an `Arg` as the last argument in its declaration. This may sound complicated, but it is pretty straightforward. Let's see an example.

Say you want to add an `--authors` flag to a program that prints the names of the authors when present. First subclass `Visitor`:

    #include "Visitor.h"
    #include <string>
    #include <iostream>

    class AuthorVisitor : public Visitor
    {
            protected:
                    string _author;
            public:
                    AuthorVisitor(const string& name ) : Visitor(), _author(name) {} ;
                    void visit() { cout << "AUTHOR:  " << _author << endl;  exit(0); };
    };

Now include this class definition somewhere and go about creating your command line. When you create the author switch, add the `AuthorVisitor` pointer as follows:

                    SwitchArg author("a","author","Prints author name", false,
                                             new AuthorVisitor("Homer J. Simpson") );
                    cmd.add( author );

Now, any time the `-a` or `--author` flag is specified, the program will print the author name, Homer J. Simpson and exit without processing any further (as specified in the `visit()` method).

## More Information

For more information, look at the API Documentation and the examples included with the distribution.

Happy coding!