Hi Volodya,
Thank you for your reply. I have placed my code, improved, into the validate() function now (see below). Thats a good idea anyway, this way it works on input from any source. I am still stuck with the issue of how to test whether users specified a vector or not as return target in their options_description, that is: ("Tex.GaussSigma", po::value<float>(&fTexGaussSigma) , "Tex.GaussSigma") or ("Tex.Color" , po::value
(&vfTexColor), "Expt.Color") Due to the very complicated flow (if you've just looked at the code for a few hours) I find it hard to figure out. I suppose i have to run typeid(*something*).name() to get the type of some variable and then check if its a vector or not. But what should be in the place of *something*?
I think you are changing the validate overload that is for vectors, not? It won't ever be called for non-vectors.
I indeed changed the validate() function that would only be called for vectors, good point! I was convinced by my memory when I wrote that email that I saw that function process all options, indeed it only processes the ones specified to be vector. Thanks!
As a general point, do you think this would be a good addition to the parser, that is, would you want to incorporate this kind of extention into the Boost release? It is a much easier way of specifying a vector, whether on the command line or from another source without having to resort to positional options, which are not a good solution for every source and situation. Compare (for command line) [--test "(1 2)"] with [--test 1 --test 2].
I am not yet sure this is good addition. In any case, it would be better to first allow to specify custom validate function for a given option.
I see that it is possible to define/override the validator for a user-defined data-type/class, this is not what you are suggesting, right? Instead, you are suggesting to make it possible to store a custom validator function in the option_description, which would then be called instead, right? Hmm, that would do the trick too, though that operates on a conceptually different level. I would then have to specify that custom validator for every option of type vector<T>. Instead, this is a suggestion for enhanced syntax for specifying vectors (that is, options that can occur multiple times) on the command line, in a config file or even in the environment variable (well, who'd do that?). It will not break any existing option input systems defined by users. IMHO, allowing this enhanced syntax is a simple, local change to the validate function for vectors that can be made quickly, whereas allowing to specify a custom validate function for a given option will be a much bigger hassle, though also a necessary thing (say you want only even ints as input for whatever reason, you'll need this). I'll do the coding (still need to take care of vectors of strings) and I'll put it in as a feature request/bug report so we can discuss this at the appropriate place.
Lastly, in an old post (cant find it now, was 2005 or 2006) a user asked whether it was possible to do po::parse_config_file(InitFileName,poInit,true); instead of po::parse_config_file(ifs,poInit,true); as the documentation apparently reflected this at that point. You replied that you'd fix that at that time (I believe it was you, doesn't really matter), but when i just tried it didnt work. Have you decided against it?
I honestly don't remember. If you care about this change, please file a bug at svn.boost.org, so that it's not forgotted for another 4 years.
Will do so, seems like a good addition, allowing less boilerplate in using config files.
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users