On 10/1/11 5:42 AM, Jacob Carlborg wrote:
On 2011-10-01 00:17, Andrei Alexandrescu wrote:
On 9/30/11 12:23 PM, Jacob Carlborg wrote:
On 2011-09-30 19:39, Jose Armando Garcia wrote:
On Wed, Sep 28, 2011 at 12:44 PM, Jonathan M
Davis<jmdavisp...@gmx.com> wrote:
So, my suggestion is that we create a GetOpt struct which contains
all of the
options for getopt, and we make getopt a member function of that
struct.
Making it a struct gives you a design flexibility that really is an
illusion. Most people it not all people use getopt to parse command
line param. Giving the user the flexibility to have multiple GetOpt
with different configuration when in essence they are parsing the same
share resource (the command line) is incorrect.
I don't agree. Take this command line for example:
"foo -a bar -b"
You're calling the "foo" tool with the global "-a" option, the "bar"
command/action and the "bar" specific "-b" option. This is how I would
implement that (I have no idea if it's possible with getopt but lets
assume that for now):
It is possible, and rdmd does that by using the stopOnFirstNonOption
flag.
Andrei
I forgot to mention that I don't want the order of the arguments to
matter. I should be possible to write:
"foo bar -b -a"
Or at least it should be possible to put global options anywhere in the
command line.
So I guess that would be using the passThrough option the first time
getopt is called and then using the noPassThrough option when it's
called the second time from the action implementation.
So there we have a use case for calling getopt more than once, at least
I have a use case for that.
Clearly there are legit use cases. The use of monostate does not impede
them.
Andrei
