FYI, xParam (sourceforge) seems to fulfill similar requirements. In article <[EMAIL PROTECTED]>, Rob Stewart wrote: > From: Vladimir Prus <[EMAIL PROTECTED]> >> Rob Stewart wrote: >> >> > The purpose of command line parsing is to decode the arguments >> > list into pieces of information, abstracting the syntax of the >> > command line away from the program. Thus, the library should be >> > able to understand any of various encoding schemes. >> >> That's syntantic level. I believe it should be as independent from >> meaning of options as possible: command line, preferrable, should >> be immediately parsable by humans. > > I think we're saying the same thing. My point is that the > library should abstract the parsing such that the program need > only describe the supported options and query to learn which have > been set and with what values. The format those parameters take > on the command line or in a configuration file should be hidden. > >> > The question then becomes how the library should provide the >> > values from the command line. There are a number of fundamental >> > types that could be exposed by the library: bool, long, double, >> > and string. The question is whether the library should support >> > any others. I selected those types because Boolean and string >> > parameters are obviously important, and long and double would >> > handle pretty much all numeric arguments one would put in a >> > command line. >> >> The level 2 of my library provides only syntantic representation >> of the read options. See >> >> http://zigzag.cs.msu.su:7813/program_options/html/ >> >> for the list of layers. > > I can't access that page, but I was simply suggesting that the > library can expose a rather minimal set of types gleaned from the > command line. Client code can transform from those types to > anything else desired. Boolean and string parameters are > obvious. Nothing else is needed as strings can (obviously) > represent all other arguments. > >> > Sure, you could provide a means to read a file line by line and >> > pass each line to a parser of some sort. However, given all of >> > the ways to parse the text one might find in such a file, I don't >> > see how that could be done so it is sufficiently flexible and yet >> > actually provides value. IOW, the parsing would be little more >> > than read a line, give it to the parser, read another line, give >> > it to the parser, etc. That certainly doesn't justify a special >> > library. >> >> What "special library"? > > I see two libraries in what you've proposed: one that manages > command line parsing and one that manages configuration file > parsing. If command line and configuration file parsing are > completely abstracted from the parameter > specification/management, then it's a question of what > configuration formats are provided by default, possibly bloating > client code unnecessarily. > >> > Perhaps I've missed some valuable service that should be included >> > in the proposed library, but I can't see that it should do more >> > than what I've outlined herein. If you do, please enlighten me! >> >> It looks like you don't need some of the extra features that both Gennadiy >> and myself are after. For example, custom value interpreration or automatic >> help message? > > An automatic help message is certainly useful; I simply didn't > mention it specifically. Custom value interpretation strikes me > as overkill. If your library provides a string corresponding to > a particular parameter, I can use that string in myriad ways to > produce information for my program. Putting that logic into a > command line parsing library seems over the top. > >> Could you please tell which features in both designs are unnecessary and >> should be removed? > > I don't know the full set of features either of you have provided > at the moment, but I hope the above clarifies my thoughts on the > scope of such a library. > > I'll second the question raised regarding the more complex > parsing: isn't that the job of a tool like Spirit? Be careful to > avoid doing too much in this library. You can make it really > powerful and capable, but that alone may keep too many at bay. > >
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
