From: Patrick Guio (patrick.guio_at_[hidden])
Date: 2002-01-15 06:06:39
On Tue, 15 Jan 2002, Vladimir Prus wrote:
> Patrick Guio wrote:
> No. I mean
> 1) checking that what should be int is indeed int
This is handled as you say. For now I have a specialised
Parser::Convert(string, value) for each intrinsic C++ type and the
conversion is done using the C strto* family routines. The errno (cerrno)
is used and exception is thrown. I must say that I have actually two
versions of the Parser one making use of char* (more C-style) and another
one make use of string and I am planing to replace C strto* family
routines by istringstream class.
> 2) parsing arbitrary class and thowing if the value given for it is incorrect
I guess anyone could extend its own parser by inheriting this one and
write its own Convert(string, value) routine where value is a class object.
The Parser::ParseOption functions are template member function that
parse the command line arguments for a special option and feeds the rest
of the string (or the next arg) to the Convert function
> 3) possibly checking that int in some range
> > > ii) How such thing as '-I' option to a compiler may be implemented
> > > (example please).
> > I have added a new member function ParseOption, actually a template
> > member function that do the job,
> > template<class T>
> > bool ParseOptions(int key, vector<T> &values) const;
> > So the option -I is added as I explained and every occurences of -Idir
> > will be parsed in a vector<string> for example.
> Okay. Then the next question is: why you requires that options are first
> registered and then parsed by calling a function for each options. It means
> that dealing with any single option is performed in two different places. Is
> it convenient enough to write down multiple 'ParseOption' calls?
That's right but I wanted to have help / version / template-creation for
the options. Therefore I choose to first register all the options and then
> > > ii) Is there low-level access to parsed options, such as in form of
> > > vector< pair<string,/*option*/ string /*value*/> >
> > No but I guess it should not be a heavy task to provide.
> Yes, and I think it's very needed. I think that separation between the part
> which actually parses the command line and the part which performs
> assignments to program variables is important to make a library usable.
> I have also to remark that support for multiple option styles was a popular
> desire in previous discussions on the subject.
This is supported in the form of aliases registration.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk