On 03/24/2018 09:36 AM, H. S. Teoh wrote:
On Sat, Mar 24, 2018 at 08:27:48AM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
At a point where a realistic benchmarks shows a need. Without a motivating
measurement, making getopt faster would be a waste of time.
[...]
Guys, for crying out loud, my original complaint was not *performance*,
but that the (strange) choice of algorithm for getopt resulted in the
very counterintuitive behaviour that the order options are processed
depends on the order of option declarations rather than the order they
were specified on the command-line.
I'd have a difficult time interpreting the following as not
performance-related:
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.
Anyhow. Right now the order of processing is the same as the lexical
order in which flags are passed to getopt. There may be use cases for
which that's the more desirable way to go about things, so if you author
a PR to change the order you'd need to build an argument on why
command-line order is better. FWIW the traditional POSIX doctrine makes
behavior of flags independent of their order, which would imply the
current choice is more natural.
This makes it basically impossible
to implement certain styles of option processing, such as that employed
in the popular ImageMagick suite of tools, where it matters that options
are processed in the order they are specified by the user, rather than
some arbitrary (to a user who doesn't and shouldn't care to know the
code) predetermined order.
This is an exaggeration. Yes you can't process with lambdas. You can
always collect options first, process after. This is a well-supported
use case.
My complaint about the quadratic algorithm was not in the fact that it's
quadratic, but that it exhibited this strange (and annoying!) behaviour,
especially since the saner (IMO) non-quadratic algorithm would have been
the expected choice in the first place, that would *not* have had this
problem. It felt almost like we went out of our way just to make things
counterintuitive, with slowness added as a cherry on top.
I want to be convinced. I think you'd need to build a better case on why
you consider one behavior intuitive and the other counterintuitive.
Andrei
