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-08 17:16:44

> From: Stewart, Robert
> Let me clarify something that has just occurred to me.  I've been
> writing strictly in the abstract about a compile time bounded
> type and a runtime bounded type and about names for them.  I've
> not been making any specific references to your types as they now
> exist.

OK, sounds reasonable. The thing is that the "bounded" class template is universal and equally suitable for dynamic and static
bounds. The only reason for existence of "bounded_int" is to save some typing when defining bounded types that have bounds
expressible as compile time constant expressions. So instead of:

bounded< int, boost::mpl::integral_c<int, 0>, boost::mpl::integral_c<int, 10> >

you can just say:

bounded_int<int, 0, 10>

So yes - the "rt_bounded"/"ct_bounded" abstraction doesn't map to "bounded"/"bounded_int" and what I'm asking for is NOT a name for
bounded class with bounds that don't change, but a better name for "bounded_int".

> > There are even cases when "bounded_int" cannot be used to
> > define static bounds and you have to use "bounded" instead
> > these are all the cases where the bounds cannot be expressed
> > directly using compile time constant expressions, e.g. for
> > floats or rational numbers. See the example with rational
> > numbers in the second part of this subsection:
> > <http://tinyurl.com/332vmf5#constrained_value.tutorial.compile_time_fixed_bounds>
> 
> In which case the type cannot be compile time bound and a runtime
> bound type must be used.  I see no problem here.

Strictly speaking it's not a runtime bound. You cannot change the value of quarter2type object. It has no storage and only expresses
some fixed value by its type, just like boost::mpl::integral_c does. Here's the difference (using types from the example above):

bounded<rational>::type rt_rational;
change_upper_bound(rt_rational, rational(1, 3)); // OK - can change bounds at runtime

bounded<rational, quarter2type, half2type>::type ct_rational;
change_upper_bound(ct_rational, rational(1, 3)); // COMPILATION ERROR!

> Making things specific, I'd like to see your bounded class
> template be an implementation detail with two public types that
> use it to do the heavy lifting.  (If you think that is
> insufficient for some reason, then expose all three with your
> current bounded class template being documented as the advanced
> form.)

I see no big advantage in doing so - the hypothetical "rt_bounded" class would then serve similar purpose as "bounded_int", that is
wrapping "bounded" to save a few keystrokes, but as opposed to "bounded_int" it would save them only in rare cases (for instance
when you would be overriding the default error policy) - most of the time there would be no difference, because defining a type with
runtime bounds is as simple as:

bounded<int>::type my_runtime_bounded_int;

And for cases like rationals or floats with fixed bounds you would have to use "bounded" anyway, so it cannot become an
implementation detail only.

> From: vicente.botet
> Sorr bau I dont see the difference. I consider ratio<N,D> to express a compile time constant through a
> type, as integral_c or integral_constant do.

Sorry, maybe I've been unclear - by "compile time constant" I mean what C++ Standard describes as constant expression. Therefore, a
type is not a compile time constant in this sense.

Best regards,
Robert