From: Jeff Garland Anyway, I'm willing to be the review manager if that helps.
That's great, thanks!
I'm a little concerned with the dynamic changeability of the checking policy on bounded. I think that design decision will lead to function call overhead not present in the original implementation...even for bounded_int where the constraints can all be inline and fixed at compile time. I'd rather have 2 types if need be to allow maximum efficiency for the static cases.
I wouldn't consider this a great issue. My experiments with compilation to assembly code show that compilers are able to optimise-away all (or at least much of) the abstraction easily (e.g. see http://article.gmane.org/gmane.comp.lib.boost.devel/164478). Moreover, I think that breaking the implementation into two cases based on efficiency reasons would break one of the basic Boost guidelines: "Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries."
Couple thoughts on the docs. I didn't see Christopher Diggins acknowledged anywhere.
This is what I was going to do. ;-)
Second thing is that it would be nice to have tutorial style docs to walk someone thru use of writing a custom constraints (ok there's a simple one there), but also how to replace the provided exceptions with custom exceptions
TBD
I've written a constrained_string type which provides similar capabilities for strings. A typical use case is to only allow construction with a fixed set of strings -- basically like an enum
Maybe it would be a good idea to write more general constraint policy, which allows for values of any type that belong to a specified set.
Another form allows fancy regex checking:
This one is nice too. ;-) Best regards, Robert