On Dec 7, 2009, at 11:50 AM, Roy Stogner wrote: > 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.
We struggle with this right now... we usually go the route of setting something out of bounds... I suppose that have_variable() might be a better idea... > 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. Can you include other config files now?!?! That's something my users actually want right now... Derek ------------------------------------------------------------------------------ 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
