Hi Preston,
I've been working with boost::options, and these is one gaping hole in it, that I have noticed. There is no way to use a custom converter in the default po::typed_value class. ....... validate_mapped - used as: value<T>()->parser(validate_mapped<K,T>(first_key, first_val) + std::make_pair(second_key, second_val) + std::make_pair(third_key, third_val)) This will then allow you to specify a value of one type, but have a different type stored. This is particularly useful to allow, say: LogLevel = info and then have that actually stored as an in (say, 5) in the values.
This is cool.
I have others to do syntax validation too, so say validate_ipaddr which will ensure that it is a valid IP address before storing it, and so on.
Again, I'm not sure how much notifiers would do this too. But also consider the following.
A 'validator' that allows you to take an IP address as text, verify it is a valid IP address (hell, if someone wanted to add logic, verify it is within a certain range if they wanted to), and then store it as an in_addr_t.
This is indeed cannot be conveniently done in the current version. You can create a subclass of 'value_semantics', say, "ip_address_value_semantics_t", then create a function "ip_address_value_semantics", and use it instead of "value". But passing just the validator function is more convenient, so I intend to implement this functionality.
And all in all, the change to do this was minimal, apart from adding the 'parser' function, my xparse function is simply: if (m_parser) m_parser(value_store, new_tokens) else validate(value_store, new_tokens, (T*) 0, 0);
Feel free to e-mail me if you want my code, or want me to post it.
I understand what your change is, so I can quickly apply it myself. I'll only need to decide if it's better to provide custom parser, custom validator (called after parsing), or both. And I also need to find out what's sizeof(boost::function<....>) is ;-) Thanks, Volodya