On Mon, 07 Feb 2005 17:39:10 +0300, Vladimir Prus wrote:
I'll have a closer look at this and then decide what's the best way to mix validation of single value with validation of the whole option. This starts to resemble output formatters library which was reviewed some time ago. Well, as I mentioned, I'm currently using the version I pasted to you (actually, I've made a few modifications since, nothing major though, if you look at the current head version, you'll see the modifications).
It works quite well, and most importantly does almost everything I want. The only thing it doesn't do is allow me to 'daisy-chain' validators. In other words, do: value<int>()->parse(validate_multiple_of(5, validate_min(5))) The validate_multiple_of would use validate_min to retrieve the value, which would in turn use the default validator to do the conversion. This, obviously, would be a way to ensure both that the value is both a multiple of five, and not below five. Useful for, say: validate_multiple_of(512, validate_min(2048)) - ie. only take values evenly divisible by 512 (block size), with a minimum of 2k. Of course, I could write a custom validator to do just this, but it'd be nice to have a mechanism to do this built in, but I've not figured out a sane way to do it without making the template syntax really ugly.
Incidentally, why is 'arg' a global variable? This is horribly thread-unsafe - it would be better to have the argument name passed to value_semantic in its parse function or something - because global variables really suck *nod* - especially for multi-threaded applications (not that I plan to have two parses running at once, but it IS possible).
This a variable which is never modified. What thread-safely problems do you mean? 'arg' must be modified, else it would not work with, say, the name() function. I assume this is set to the 'currently processing value', for both help, and to fill in the correct value when an exception is thrown (if I throw invalid_option_value, for example). If this is the case, if two threads run their own po::parse_* functions at the same time, then it might get confused, since from what I could tell, 'arg' is not localized to any specific parse, nor is it thread specific storage.
I've not tested this, of course :) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)