Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk