|
Boost : |
Subject: Re: [boost] program_options custom validators
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-07-11 12:18:57
On Sat, Jul 11, 2009 at 2:21 AM, Vladimir Prus<vladimir_at_[hidden]> wrote:
> Zachary Turner wrote:
>
>> Hello, recently I was faced with a situation of writing a custom
>> validator for a certain command line option I wanted to handle. The
>> validator was supposed to check whether the value on the command line
>> was in a certain range. After some head scratching, I realized
>> there's no elegant way to do this with the current validation overload
>> function. In the end I just ended up doing the validation after the
>> options had been parsed.
>>
>> I was thinking about a good way to support this, and I thought that
>> maybe the best way is to add an additional value semantic so that the
>> validate function could instead be:
>>
>> template<class T, class validation_data>
>> void validate(boost::any& v, const std::vector<std::string>& values,
>> const validation_data& data, T* target_type, int);
>>
>>
>> and we could write
>>
>> add_options() ("test", value<int>()->validate(boost::interval<int>(1, 10)) );
>>
>> this would require the user to provide the following overload:
>>
>> void validate(boost::any& v, std::vector<std::string>& values, const
>> boost::interval<int>& data, int* target_type, int);
>
> Would it be a more generally useful approach to add value_semantics::validate that
> can take any function, and call that, in preference to the free-standing validate?
> Then, you'd implement is_in_range helper and use it like
>
> add_options() ("test", value<int>()->validate(is_in_range(1, 10)) );
>
> ?
>
> That is something I wanted to do for a while, but never found the time.
>
> - Volodya
>
Actually I was thinking about that too and yes that would be more
useful. I'm generally opposed to customization by free-standing
overloads because it means you can customize only once per type,
rather than per instance. So I was trying to do it with the minimum
possible amount of code changes. Is there a way to implement what you
suggest without breaking existing code?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk