fixed a bug: the parser now correctly parses parameters of the form

-Pvalue

This will now produce 'value'. The buggy parser would parse 'alue' here. I am truly and deeply
ashamed to have created such an off-by-one error.

Marc assumed this was wanted behaviour (so that it should read: -P=value)
I must admit that this is a logical conclusion, though it was merely a side-effect
of the error. To not force Marc to rewrite the tutorial and his way of working with
EO, I decided to make a feature out of the bug, so that now the parser will parse:

-Pvalue
-P=value

and of course the true and blue:

-Parameter=value

I will now go and check if I sent out some crappy papers caused by this bug (as I've been using eo!)
This commit is contained in:
maartenkeijzer 2001-02-13 12:38:19 +00:00
commit 262869d0ae

View file

@ -37,7 +37,7 @@ eoParameterLoader::~eoParameterLoader()
eoParser::eoParser ( int _argc, char **_argv , string _programDescription, string _lFileParamName, char _shortHand) :
programName( _argv[0]),
programName( _argv[0]),
programDescription( _programDescription),
needHelp(false, "help", "Prints this message", 'h')
{
@ -144,7 +144,7 @@ void eoParser::readFrom(istream& is)
string str;
while (is >> str)
{
if (str[0] == '#')
{ // skip the rest of the line
string tempStr;
@ -179,10 +179,22 @@ void eoParser::readFrom(istream& is)
}
else // it should be a char
{
string value = "1";
if (str.size() > 2)
value = string(str.begin() + 3, str.end());
shortNameMap[str[1]] = value;
string value = "1"; // flags do not need a special
if (str.size() >= 2)
{
if (str[2] == '=')
{
if (str.size() >= 3)
value = string(str.begin() + 3, str.end());
}
else
{
value = string(str.begin() + 2, str.end());
}
}
shortNameMap[str[1]] = value;
}
}
}
@ -271,7 +283,7 @@ void eoParser::printHelp(ostream& os)
if (p->second->shortName())
os << "-" << p->second->shortName() << ", ";
os << "--" <<p->second->longName() <<":\t"
<< p->second->description() ;