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
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):
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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk