From: Jeff Garland (jeff_at_[hidden])
Date: 2007-11-12 06:32:59
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
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
> 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. ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk