From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-23 00:36:29
Tanton Gibbs wrote:
> I have to say that I'm a little torn over this library. I really like its
> simplicity and usefulness; however, I wish it were more of a facade on a
> more complex library. For example, I would like to be able to have
> multiple config file parsers for winini, tag=value,xml, or other config
> file types.
I understand why you might need additional parsers. The important point
about them is that it's easy to add them. Since the parsing part is
hidden behing the "parse*" functions, to add a new parser one would need to
only to add "parse_xml_config_file" function. Probably some of such
functions must be added to the library --- but that depends on user
> Also, I would like to see canned custom parsers for
> -fparm/-fno-parm and
> +parm -parm syntax.
I think it's possible to collect some number of canned parsers that are
> Here are my addressable comments
> (1) I would like to have a find_if and count_if function as I often want
> find a parameter of the format *.field.* It doesn't matter what the *'s
> as long as it contains .field. They should both take a function as a
Those functions should be added to variables_map, right?
> (2) Someone else mentioned custom parameter verification. I'm kind of
> on this. I don't mind it if you could pass in an arbitrary functor (like
> lambda library functor). However, I also don't mind doing the validation
> outside of the library. I definitely don't want the parameter function to
> take arbitrary parameters (like the min/max idea presented earlier) as
> that would just be too confusing.
I think 'parameter' function should not take arbitrary parameter, or we'll
be lost in overloading ambiguities. However, user or I can write more
functions, similiar in spirit to 'parameter', but with added semantics.
("compression", range_parameter("n", 1, 9), "desired compression")
> (3) As another pointed out, the documentation is definitely lacking. I
> would like less of code documentation and more of user documentation. I
> would like to see more examples with sample output and a slow moving
> tutorial that covers all of the features.
> (4) What if I want parameters to occur in a particular order? For
> example, the -kk option can only occur after the update parameter in cvs:
> cvs update -kk blah blah blah is legal
> cvs -kk update blah blah blah is not
> It would be nice to either be able to specify a mandatory ordering, or to
> able to find out the position of the parameter. If you could specify a
> mandatory ordering, then I would like it to be relative. For instance
> every parameter with ordering level 0 must appear before every parameter
> with ordering level 1; however, parameters with ordering level 0 can
> appear in any order amongst themselves.
Something like that could be added, but I'll try to do that only if
seriously pressed by some user. The reason is that I find such command line
syntax to be confusing. As I've mentioned some time ago, in CVS the same
option means different things depending on position and this leads to user
confusion, not convenience.
> Now for comments on what other people have said.
> (1) I also like parameter as the last argument instead of the middle
> one...it just flows better to me.
> (2) I like the parameter function and don't really like the syntax that
> used the >> operator...it just looks odd to me.
> (3) I like the parameter function taking the argument by pointer as it is
> easier to understand what is happening.
> (4) The exception name "error" doesn't bother me...I kinda like it :)
> All in all it looks to be a good library. However, I may have missed the
> ability to define a custom config file format. If I didn't then I fully
> think that needs to be added or config files need to be dropped entirely.
As I've mentioned above, adding new config file format is as simple as
adding a new function. That's simple, but it works.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk