Hi Pavol,
>> 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.
The story is a bit more complex. There's a 'validator' which can be set to
do anything.
desc.add_options()
("foo", "bar").validator(your_nifty_functor)
;
However, say you extensively use value ranges. You'd have to write this
".validator()" part everywhere, and "your_nifty_functor" will actually be
creating of some functor, which is passed two values. This all is verbose.
You can, however, write a single function, say int_range, which will take
parameter name, and two ints, and set up the validation function. That
would be more convenient.
The only problem with current 'validator' is that it should validate
*string* and return the value. So, the example given by Tanton:
_1 >= 1 && _1 <= 9)
would not really work --- the validator function is given a string. It's
probably possible to use 'notify' callback to do such kind of validation,
though. Or add another validator --- which is given converted value.
>> > * 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.
Ah... ok. Indeed --- the validator can do that already, and in case of
string validation, the current code will work.
>> 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.
Added to my todo already.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
