[boost] Re: boost::program_options extensions

From: Preston A. Elder (prez_at_[hidden])
Date: 2005-02-08 00:04:35

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)