Boost logo

Boost :

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 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 looks doable.

>> Another form allows fancy regex checking:
> This one is nice too. ;-)

Thx :-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at