Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-26 01:41:08

Pavol Droba wrote:

>> 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.
> I see. However I think this is a little bit clumsy to use. I think it may
> be better to strip validation from the conversion.
> What I had in mind is an extension to po::parameter funtion to something
> like
> template< typename T >
> *unspecified* po::parameter<T>(
> string parameter_name,
> T& variable,
> const boost::function1<bool, T)& validator );
> so the framework would convert string parameter to a specified type and
> then run the validator functor on the result to validate it.

I was actually thinking about splitting current "validator" into
"interpreter", which converts string to value and validator proper. That
should allow to write

      ("compression", parameter<int>("n"), "compression quality").
             validator(1 < _1 && _1 <= 9)

With this feature in place, adding validator as additional argument to
'parameter' can be considered a convenience. (Now, there are 3 ideas for
additional arguments to 'parameter', so I can't decide right now).

One problem: the above would require implementation tricks. The value
extracted from string is stored in boost::any. Sure, you can't pass
boost::any to the lambda function above, so some means to recover the type
stored in any would be needed. I'm not yet sure this will be all that big
problem, though.

>> > 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.
> That's nice. Can you post a piece of code as an example?

Attached is a complete example which uses regex library to validate option's
value. The format of value is fictional, but the main idea should be clear.
And there's example session:

    bash-2.05b$ bin/gcc/debug/regex --help
    Usage: regex [options]
    Allowed options:
      --help : produce a help screen
      -v [ --version ] : print the version number
      -m [ --magic ] arg : magic value (in NNN-NNN format)
     bash-2.05b$ bin/gcc/debug/regex -m 123
     invalid value
     bash-2.05b$ bin/gcc/debug/regex -m 123-345
    The magic is "345"

I've also realized there are no examples for custom validator now, so this
code will most likely be added to the library.


Boost list run by bdawes at, gregod at, cpdaniel at, john at