From: "Matt Doyle" <mdoyle@a-m-c.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Rob Stewart From: "Matt Doyle" <mdoyle@a-m-c.com>
From: "michael toksvig" <michaeltoksvig@yahoo.com>
Please don't overquote.
To be certain we're talking about the same thing, Michael and I have been discussing the result of a computation. Built-in types regularly undergo promotions when participating in such expressions, so the question is whether something similar should happen for a checked integral class and what form it should take. =20 Michael was positing that the result type should account for the full range of values possible from the computation. I argued against that. =20 I should also point out that built-in types don't behave that way; they can overflow silently, but they don't magically gain range. (The analogy isn't strong, but has some bearing, I think.)
I think we are talking about the same thing but from different angles, = consider this simple case;
typedef constrained_value<0, 10, policy> MyCV; MyCV a =3D 6; MyCv b =3D 8; MyCv c =3D a + b; // Should fail
If the user wants "c" to be able to hold the result of "a + b" he should = define a new type that would accommodate it.
If MyCV::operator + returns MyCV, then a + b won't work, but the overflow is only detected at runtime. If MyCV::operator + returns a new type that computes the return type as having a different range (0-20, in this case), then any two MyCV's can be added without error. The question is what happens to the result. In your example, the result is assigned to a MyCV, so the range of the result is constrained, at runtime, to 0-10, regardless of the result's type. That's MyCV's job. Either Michael's or my notion of the return type will give you the same result, at least if there is a converting constructor to account for Michael's approach. That is, MyCV would need a constructor template that accepts other checked types so long as the ranges aren't completely incompatible. For example, you wouldn't want the compiler to allow construction of a MyCV from a checked type with range 20-100. Getting back to your example, that converting constructor could accept the result because the computed range, 0-20, has values that will fit in MyCV's range. Whether the actual value assigned at runtime satisfies the range check is a separate matter. For your example, the result, 14, exceeds MyCV's maximum, so you'd get a runtime error. The real difference then, arises with how you use the result of a computation. If you pass it to a function template, for example, our approaches would result in different instantiations. My approach would retain the original range checking (0-10), whereas Michael's approach would have a new range (0-20). That's where I question the validity of his approach. If the two types were passed to a function that expected a MyCV, then it plays out the same as your example.
We are on the same page aren't we?
Are we? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;