[boost] Re: boost::program_options extensions

From: Preston A. Elder (prez_at_[hidden])
Date: 2005-01-29 22:40:20

On Fri, 28 Jan 2005 23:26:22 -0500, Preston A. Elder wrote:

> More food for thought.  Meanwhile, I'm going to alter my hacked up version
> to do the above, and I'll post a link to the code when done :)
As promised, here is a link to the code:

http://www.neuromancy.net/viewcvs/Mantra-I/include/mantra/core/typed_value.h?root=mantra&rev=1.1&view=auto

In this code, the validate functions are only there to handle how the
value being converted is stored, NOT how to convert the value.  The
validate_internal class does the actual conversion by default.  However a
substitute for this may be passed to the typed_value class - and it will
not matter whether its being stored in a vector or whatever.

As you can see, many of the user-provided validators often simply call
validate_internal to get the value, then do their own processing on it
(for example, see validate_range, which uses the default validator to get
the item before doing the range comparison).

It doesn't have to, as with validate_space (which uses some of my own code
to convert a textual space ("3k", or "5m") to a boost::uint64_t - it is
left as an exercise for the user to ensure that the typed_value class is
typed for boost::uint64_t).

You will also note I specialized the bool version of validate_internal,
just as was done with the bool version of validate in the original -
again, this calls my own function which looks for a textual version of a
boolean, and returns a tribool (the code is in 'utils.h' in the same tree
if you care :P).

This is the kind of system I REALLY hope to see inside program_options, as
it takes care of multiple data stores and custom validators all in one
fell swoop.  Including 'daisy chaining' validators (such as what
validate_range does).

Please note, some stuff in here (such as the 'duration' stuff, and
get_bool, and validate_host, etc) are kind of specific to my application,
but should not be too hard to either replicate or remove.  I am using this
in my own application right now (which is why it is in my own namespace),
and I can confirm it works :)

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).

-- 
PreZ :)
Founder. The Neuromancy Society (http://www.neuromancy.net)