First, a few for everyone: One of the features in the libMesh GetPot fork is the templated read, which gives us support for any data type with a operator>> defined. We use our own specialization for bool, since operator>> won't handle all the "true" and "True" and "TRUE" and ".true." sorts of variants people might use. Should we extend that specialization to support "0" for "false" and "1" (or even any non-zero integer/number) for "true" as well?
(yes, a libmesh user here just got bitten by assuming that ints converted to bools in input files the same way as in code) Either way, should we throw an exception instead of returning Default when an unconvertable string is encountered? Returning defaults when options are missing is a brilliant way to work, but returning defaults when options are unparseable seems excessive. If a config file has "some_val = trrue" or "some_val = faalse" in it, and someone requests a bool (or anything but a string or char*) for some_val, we ought to be able to flag that as a syntax error. Finally, if we do throw an exception, should we do that in the existing GetPot::operator(), or by adding a new function while leaving behavior unchanged in the old? I'm hate to break backwards compatibility in any way, but I can't imagine users depending on "syntax errors get silently ignored" behavior. Second, two for the libMesh people: I'd like to keep the PECOS libGRVY version of GetPot identical with the libMesh fork and Frank would like to merge some of the libMesh fork's changes back into his version. However, we're currently depending on the libMesh Threads:: wrapper to TBB for spinlocks, and adding either of those dependencies to libGRVY or to the main GetPot is out of the question. After talking with Frank, I've written a scoped_lock wrapper around the pthreads mutex to use in those cases. So my questions are: Any objection to me using pthreads as the only option and avoiding TBB here entirely? That would simplify the header, and it would work fine for Mac/Unix/Cygwin. Any objection to me using a mutex instead of a spinlock? The pthreads mutex standard is older and perhaps more widely supported. Spinlocks are probably a bit faster for every libMesh "1 thread per core" use case, but can be significantly slower in a few more general use cases. --- Roy ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
