I meant, do you know of a free implementation of getopt_long?
AutoOpts looks like it's very useful for certain situations, but there
seems to be a consensus (which I share) that it's overkill for this
project. Many programmers already know getopt_long, so they wouldn't
have to learn another system. And since getopt_long would be in APR,
we won't have to include Yet Another Third-Party Library with
Subversion. Even having the author on the dev list doesn't make up
for those factors, though it would alleviate them somewhat.
I'm sorry. I know that's a disappointment, and I can't even say for
sure it's necessarily the right call. But my intuition is that in
this case, it's better to use the more standard interface and do some
extra work manually, and I think the others involved in the
command-line code feel the same way.
(One point that may help explain my reaction: "doing the extra work
manually" sounds burdensome, but it often means that one gets more
fine-grained control over the results, so the trade-off is not as
one-sided as it sounds.)
-K
Bruce Korb <bkorb@cruzio.com> writes:
> Karl Fogel wrote:
> > Re the table: I think it's worse to have lots of empty C files sitting
> > around unused for a long time, than to have to tweak four locations
> > when adding a new command.
>
> Matter of taste then, so I'll defer to you.
>
> > The getopts_long interface is one familiar to many programmers, ...
> >
> > If you do know of such an implementation, please point the way.
>
> There _is_ my library. If one doesn't like generated text, one
> could always edit the struct by hand. I don't think it is much
> worse than the GNU getopt_long struct. It is just more constraining
> to not be able to use that information in other contexts
> (documentation). Using the struct directly also makes the interface
> more rigid. You also would loose the macro interface to the
> options. However, these are all losses of features that are not
> part of the GNU getopt_long interface anyway. My thesis: AutoOpts
> can be used the same way as the getopt_long library with approximately
> the same level of difficulty. You even get a few enhancements over
> getopt_long (i.e. the loop is handled for you). *I* would not
> choose to use that interface, though, because I wrote a generated
> wrapper around it that makes it *much* easier to work with. I could
> even generate a wrapper around the getopt_long library; I am
> disinclined just because it is a substantial subset of functionality.
Received on Sat Oct 21 14:36:14 2006