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)