Re: [boost] [constrained_value] Constrained Value review results

Subject: Re: [boost] [constrained_value] Constrained Value review results
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2010-10-15 18:48:26

> From: Stewart, Robert
> Clearly, computing bounds at compile time versus runtime can be
> considered another dimension added to that of whether the bounds
> are fixed, so there are four combinations possible: compile time
> fixed, runtime fixed, compile time unfixed, and runtime unfixed.

I don't get it - what "compile time unfixed" would be?

> When the value of the bounds is computed seems relatively
> unimportant versus whether they can be changed at runtime.  Thus,
> I think there should be two class templates that capture that
> notion.  Each of them might reasonably have a helper that makes
> specification of compile time constant bounds easier, like your
> current bounded_int does.
> 
> If that taxonomy makes sense, then we must consider names, but
> I'll not go that far unless you agree with this view of the
> types.

Well, to be honest I don't see the taxonomy making things simpler, quite the contrary - it implies several implementations instead
of just the one. Yet it only imposes unnecessary constraints restricting possible use cases, e.g. with the current "bounded" class
template you may easily create objects with one bound that is fixed at compile time and the other being mutable (for instance number
of days in a month).

I understand that the simplified model of separate classes for fixed/unfixed bounds might look more as expected by a newcomer, but
rather than multiplying entities I'd explain the existing model better in the tutorial if it's not explained well enough (is it
not?)

Best regards,
Robert