From: Pavol Droba (droba_at_[hidden])
Date: 2003-05-23 01:29:05
On Fri, May 23, 2003 at 09:15:58AM +0400, Vladimir Prus wrote:
> I'll keep this in mind. In fact, I plan to convert all the documentation
> into BoostBook is the library is accepted. The Doxygen is very nice --- in
> fact, it helps very much to keep everything documented. But I found it
> rather limiting for writing various "overview" pages. Hope new
> documentation will be better.
> > * Validation
> > Library allows to supports validation and parsing of option parameters,
> > but I thinks it is rather limited. It is possible to define
> > user-specific behaviour, but it would be helpful, if some common
> > formats would be suported.
> > For instance:
> > * Various integer types ( not just int ) with boundary checking.
> > Something like
> > paramter<int>( "count", 1, 4, &count ) // 1-Min and 4-Max
> > value
> It's funny that the very first prototype version had this facility. In
> surely can be added to the current version if there's such need.
I like the idea proposed by Tanton. po::parameter should have a validation
predicate as an argument.
A reasonable set of arguments can be provided by library, and the user can always
provide a specific ones.
> > * Format specification and checking for string. Regex specification
> > of something like scanf would be nice.
> > This can be useful for example to check if the parameter is a
> > filename.
> Could you clarify a bit how scanf-like specification can work? You mean it
> can be used to specify syntax?
I mean something like "%02.4f" or something like that... it is just an idea. If there
would be a validation predicate as an argument, regex library can be used to define
regex predicate which would cover most of the cases.
> > * Environment & Others
> > The library tries to unify the access to program options from command
> > line and from ini files. This is very nice feature because it is
> > removing the need for doing generaly the same thing twice. It would be
> > nice if some other sources of paramers could be incorporated as well.
> > Particulary the enviromnmet is often used to exchange arguments. Given
> > the fact that it consist of a set of pairs "variable=value" it is very
> > similar to the ini file and so it souldn't be hard to implement.
> Thanks for the suggestion! It's quite right.
> > For windows platform the registry comes to play as another source of
> > options.
> Yep, that source was considered as alternative from the very start. I've
> seen some project start with a command line, then add config files and then
> need registry on Windows. Registry is not yet supported because I wanted to
> find out if there's support to the idea of uniform access to all
> configuration means.
I definitely like the idea of the uniform access. It would be only welcome if the library
can cover more sources of options.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk