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.
We're in complete agreement until now. And I think precisely that is implemented. > > > 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. There is rather minimal set. For simple utilities I myself prefer to get list of option/arguments (represented as strings), and then use them. > > > 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. I don't understand what you mean by "bloating". With shared library, the size is not that important: client code includes only call to the functions it uses, and loading shared libraries is fast. For static library, unused code will not be even linked in. > > > 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. Why? Personally, if I have 10 int parameters on command line, I don't want to convert them all to integers by hand, but want the library to be able to do this for me. If you don't want this functionality, don't use it. The only support from the library part is ability to call user-provided callback. I believe this is quite simple idea. > > 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. Other than the question of custom value interpretation, I see no big objections. > 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. For more complex parsing, you can use any tool you like. As I've mentioned before, if you have circles description or C expression as value of some option, you're free to write Spirit parser, and tell the library to use it. As for keeping things simple --- I agree. Basically, that's why I don't like policy-based approach --- what I have seems to be adequate, and adding more complexity/flexibility should be done only if required. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
