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
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
> 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
> 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. ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk