> Since this discussion has been mostly between two folks, I > thought I'd add my take on command line and configuration file > handling.
Finnaly. I started to think that it's only me and Volodya who have an interest in a subject. > 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. Agree here. That's why lookup_policy is introduced - to support different logic in parameter identification. > 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. > > You could use std::istream-based input mechanisms to allow types > to parse an input string, thus making the argument to variable > conversion extensible. Beyond that, I don't think anything is > needed. Yes. Once parameter is identified the second task is to parse out value from input. I separated this logic into interpreter class. Default one use lexical_cast(istream) based solution. But if for whatever reason you prefer scanf you will be able to use one. > As for configuration files, there are myriad formats available > and I don't think parsing them has anything to do with command > lines. Agree here. > I can see a special redirection mechanism in which you > tell the command line library that all or some of the arguments > that would otherwise be on the command line will appear in a > file, but the format of such a file should be confined to a > series of lines that conform to what could otherwise have been on > the command line. This is only one of the possible solutions to the task of providing unified program parameters interface. > Some configuration files include CPP-like preprocessing symbols > and directives. Some are section based (like Windows INI files). > Some are just free form lines of text. Some use special symbols > to delimit required columns of data. I don't think there's a > good way to standardize this. > > 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. Look on what my config_file iterator is doing. Don't you think it's reusable and worth separating into library? Gennadiy. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
