From: Gordon Woodhull On Dec 9, 2008, at 9:21 AM, Jesse Perla wrote:
I absolutely agree that if this library was purely for bounds testing, managing invariants, etc, that predicates are sufficient. But for high performance numerics, that is not what would happen. First of all, you would turn off automatic testing at runtime.
I think this is another good reason to allow disabling of these asserts specifically (as opposed to disabling all boost asserts).
I think Jesse meant turning off constraint checking in general, not only the invariant asserts.
But one of the key value of this library, in both release/debug, for those examples is to get information about the bounds and intervals from the type itself for generic algorithms. A predicate as a function can test assignment, but it can't give back structured data for these algorithms. If you can show me how the testing predicate can be easily queried within this framework for the type metadata itself(e.g. a list of intervals), then I will shut up.
Well, just the way you query within_bounds predicate to get the values of bounds etc. The point is to provide a wrapper for a predicate which allows you to access all its data, but "overwrites" the invocation operator to always return true. Maybe it could look like this (not tested, not contemplated much): template<typename P> struct true_predicate_wrapper : public P { true_predicate_wrapper() : P() {} true_predicate_wrapper(const P & p) : P(p) {} template<typename V> bool operator () (V) const { return true; } } You can use P predicate (containing all the data like intervals list) in debug mode and true_predicate_wrapper<P> in release mode to retain all the information, but get rid of constraint checks. Best regards, Robert