Re: [boost] [rfc] constrained_value (Was: constrained_value.hpp)

From: Robert Kawulak (kawulak_at_[hidden])
Date: 2007-11-11 20:48:13

> 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