From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-18 08:09:17
David A. Greene wrote:
> rogeeff wrote:
> >>The values are not the problem. The problem is the myriad of
> >>command-line formats. Is there an '=' between the option name
> >>and value, a space, a comma, nothing? Is this a single letter
> >>option? I multi-character option? One dash or two? Is any
> >>nesting involved?
> > In reallity not that much. And all cases you described could be
> > trivially parsed by much simple means.
> How? Which means would those be?
I'm currently in process of writing a code that is intended to deal with all
the options style that I've aware of. So far it looks like some
disambiguation decisions must be made and somebody might not like them. On
the other hand, I don't see much implementation problems.
I plan to write this code ASAP and then we can see if it's adequate.
Actually, I intend to make the interface similar to that of code by Bill
Kempf, which should be somewhere in the files area. (Unfortunately, it has
fewer way of tweaking syntax than I'd like). If I succeed, then there will be
a flexible command line parser with only a few dependencies on standard
headers, which will be usable separately and as low-level part for the
already-written semantic part. I think that in this case there simply won't
be a reason to use Spirit.
On the other hand, maybe using different parsing back-ends can be easily
implemented. But this is later....
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk