Am I reading this wrong, or is std.getopt *really* this stupid?
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Mar 23 23:29:48 UTC 2018
I just ran into this seemingly small problem:
void main(string[] args) {
string[] searchPaths;
getopt(args,
"l", (string opt, string arg) {
// searches through searchPaths
openFile(arg);
},
"I", (string opt, string arg) {
searchPaths ~= arg;
},
...
);
}
Running the program with:
program -I /path/to -l myfile
causes a runtime error that 'myfile' cannot be found, even though it
actually exists in /path/to/*. I thought it was odd, since obviously
the -I is parsed before the -l, so searchPaths should already be set
when -l is seen, right?
Well, looking at the implementation of std.getopt turned up the
disturbing fact that the program's argument list is actually scanned
*multiple times*, one for each possible option(!). Besides the bogonity
that whether or not searchPaths will be set prior to finding -l depends
on the order of arguments passed to getopt(), this also represents an
O(n*m) complexity in scanning program arguments, where n = number of
arguments and m = number of possible options.
And this is not to mention the fact that getoptImpl is *recursive
template*. Why, oh why?
Am I the only one who thinks the current implementation of getopt() is
really stupid?? Can somebody please talk some sense into me, or point
out something really obvious that I'm missing?
T
--
Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.
More information about the Digitalmars-d
mailing list