erwin - 2005-04-22


First, thanks a lot for this package. I wanted to introduce some Command Line Parsing tool in our project and after googling a bit couldn't find anything better than this tool.

So I have been playing with it for a few days already and found some problem with MultiArg argument and some compiling warnings I would like to get rid of:

1. the major problem is that I cannot use xorAdd with MultiArg argument. There is an exception thrown while parsing: "PARSE ERROR: Two many arguments!"

After taking a closer look to the code, I guess the problem lies in a way how you calculate the number of required parameters:
it is accumulated using the following operator:
  requiredCount += _xorHandler.check( *it ); in CmdLine::parse() function where *it is the currently matching argument.
Function check() in case if the argument was added using xorAdd() returns this:
// return the number of required args that have now
// been set
    return (int)_orList[i].size();
obviously when we have a MultiArg in some _orList[i] every processing of this arg will increase requiredCount variable on the size of this list, and result in requiredCount value bigger than that must have been in fact and leads to throwing an exception further in code of parse() function.

It looks like there is also a simple solution to fix this problem:
   return (int)_orList[i].size();
one could use
   return ( a->isRequired() )? (int)_orList[i].size(): 0;

// exactly as it's checked for normal (not xorAdd) case.

Imho it is not nice designed but it fits the current XorHandler design (which was as it looks like added later).

Could you give some comments on this issue?
If you think it's worth I could add bug request or something.

There are also a few minor issues:

2. MultiArg::processArg() doesnt' set _alreadySet variable to true (as ValArg::processArg() does). I don't know whether it's done delibirately or not, but that leads to the problem that when I want to check what of "xorAdded" arguments was set using Arg::isSet() function in case of MultiArg it returns false (what is false ;-)).

3. After compiling the project with stricter warning policy there have been some warnings appeared (gcc version is 3.4.3, tclap version is 1.0.5) namely in functions Multi(Value)Arg::short(long)Id(val)
variable val is not used. Instead _typeDesc is used to form both these ids.
Is it a bug and val variable should be still used or it's done deliberately? Then why do we need the function parameter val in base class(Arg) interface at all?

ok. That's it for the moment :-)
I will change this stuff so far locally and be glad to hear your comments on mentioned issues.