Re: [lmi] Which getopt should we use?

[Greg Chicares]

On 2007-05-04 23:02Z, Vadim Zeitlin wrote:
> On Fri, 04 May 2007 22:47:48 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> We anticipate new uses for the command-line version of lmi. I've
> GC> been working with a glib++ version of getopt, and have come to
> GC> the belated realization that it's been deprecated for years, so
> GC> it seems like a good idea to replace it. We want something that
> GC> works on a variety of OSs and with different compilers.
> 
>  Would using wxCmdLineParser be acceptable? I'll be the first to admit that
> it's far from ideal but it's still way ahead of getopt IMHO.

It's closer to my ideal than the others I've looked at. But it
would create a dependency on wx, which I want to avoid for the
command-line version of lmi.

I looked at boost::program_options, too. It's twenty-eight files,
and maybe it has to be that big given its ambitious scope, but
it's much more than we need. Besides, many of its tests are
reported to fail with MinGW gcc and with comeau.

And using gnulib isn't as simple as it seemed. Take, for example,
getsubopt(), which is the only thing I want right now that's not
in the libg++ adaptation we're presently using. gnulib has a tiny
getsubopt() implementation, and I'm sure it's well tested, but
it's not written in any standard language. I can fix that, adding:

  char* strchrnul(char const* s, int c)
  {
      char* z = strchr(s, c);
      return z ? z : strchr(s, '\0');
  }

but I can just as well use std::getline() with a ',' delimiter.
That's what I'll do for now; we can consider replacing the whole
thing sometime in the indefinite future.