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

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
> 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