On Mon, 7 Dec 2009, Roy Stogner wrote: > On Mon, 7 Dec 2009, Derek Gaston wrote: > >> I suspect that the default templated version of __convert_to_type() >> was failing to convert a std::string with "true" in it to a bool on >> the line that does "in_string >> retval". In which case the default >> value gets returned. > > Ah! Good catch. It looks like you have to pass a boolalpha > manipulator to std::istream and descendants before they'll read > alphanumeric inputs for booleans. Would you try that (it's my new > update) and see if it works? If it doesn't at least pick up "True", > "true", "TRUE", and the converse then we'll use a hand-crafted > specialization... but although the C++ standard library is pretty > anemic, I'd hope it can at least convert strings to bools reliably.
Oh, and this actually brings up another point - using a type T argument is great for inferring return type, and it's great when you actually have a default argument to reduce the size of your config files, but sometimes you want to force a value to be specified in the config, and most of the time you want to scream bloody murder if you see a value that's specified in the config but not parseable. When you want to force a value to be specified, sometimes you can make your "default" into a ludicrously out-of-bounds value and then test to make sure it changed, but obviously that won't work for bools. So we need another form of operator(), which takes an input argument to infer type but which doesn't use it as a default. Maybe add a third argument? inline T operator()(const char* VarName, const T& Default, bool allow_default = true) const; Or maybe that's just overkill, and people should just call assert(have_variable(VarName)) separately, which would work fine as long as we handle unparseable values better. And as for what to do with unparseable values, I'm thinking we just mimic the istream interface? rdstate()/setstate()/clear() in general, and an exception mask in exceptions() (maybe with a #ifdef GETPOT_ENABLE_EXCEPTIONS wrapped around such code for compatibility with aging compilers?) None of this would go in right now; just something to add after I try submitting this upstream. Major feature additions (including the "include other config files" functionality that motivated my messing around with getpot in the first place) can wait until we know whether they're going into getpot 1.3 or just libmesh_forked_getpot 1.1. --- Roy ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
