Robert Kawulak wrote:
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).
Hmm, I'm dubious that this testcase is representative. Because you have a fixed const there is apparently no checking required...unlikely to work in most cases. Also, you still have the function call overhead...so I'm still leary that instead of 2 compares you get 2 compares plus the overhead in your example.
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."
Well, this type is an 'int replacement' so efficiency is a concern here. I guess I'm ok leaving it for now, but I'd like to see some deeper testing or the removal of the dynamic interface -- it can always be added later if someone makes a compelling use case for it. Personally, I don't think I have a need for it.
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.
Good idea....it looks doable.
Another form allows fancy regex checking:
This one is nice too. ;-)
Thx :-) Jeff