Re: [boost] [constrained-value] additional features
From: Robert Kawulak
I don't think it's a good idea to use constrained floats - explanation is attached at the bottom of this message (it's an excerpt from a message in another thread about this library). Anyway - use at your own risk! :P
Strange, I've been doing it in Ada for 15+ years and it's been of /great/ assistance there!! ;-) The problem with floats is when you have literals (and sometimes when you have equivalence checks), you don't always get quite what you expect and that would apply when specifying the lower & upper bounds. /But/ you have that with plain-old-code checks anyway, and this library is really just about allowing people to replace these tiresome and repetitive checks with something "automagic". Given that most of the ranges I'm interested in are real numbers this is a "must have" in my book.
I'd also quite like the idea of being able to retrieve the range of a constrained value [...] typedef bounded_int<int, 0, 359>::type degrees_in_circle;
Not a problem, it's already been there:
degrees_in_circle::constraint_type::lower_gen_type::value
I know it's not pretty, but I can't help it - this is the price of modularity. ;-)
BTW, to get runtime value in case of stored bounds:
bounded<int>::type b; // ... b.constraint().lower_bound()
This works for compile-time bounds too (i.e., for bounded_int etc.).
Ok, I'll go and dig deeper. It would be nice to be able to say: bounded_int<int, 0, 100>::type b; std::cout << "first = " << b.first() << "\n" << "last = " << b.last() << std::endl; And get: first = 0 last = 100 Cheers -- Martin
From: Martin Dowie Strange, I've been doing it in Ada for 15+ years and it's been of /great/ assistance there!! ;-)
I don't know the exact details of Ada's floats, but knowing Ada's approach in general I'd suspect it probably doesn't allow for surprises like those described below (excerpt from http://hal.archives-ouvertes.fr/hal-00128124/en/): [qoute] [...] there exist a number of myths of what IEEE-compliance really entails from the point of view of programsemantics. We shall discuss the following myths, among others: . "Since C's float (resp. double) type is mapped to IEEE single (resp. double) precision arithmetic, arithmetic operations have a uniquely de- fined meaning across platforms." . "Arithmetic operations are deterministic; that is, if I do z=x+y in two places in the same program and my program never touches x and y in the meantime, then the results should be the same." . A variant: "If x < 1 tests true at one point, then x < 1 stays true later if I never modify x." . "The same program, strictly compliant with the C standard with no "un- defined behaviours", should yield identical results if compiled on the same IEEE-compliant platform by different compliant compilers." [end qoute] The 3rd point is crucial WRT using floats with constrained<>.
/But/ you have that with plain-old-code checks anyway, and this library is really just about allowing people to replace these tiresome and repetitive checks with something "automagic".
Right, but checking a float value like this is simply wrong: float f = 1.5; assert(f == 1.5); Constrained types depend on exact comparison, and this is why they're not compatible with built-in floats.
Given that most of the ranges I'm interested in are real numbers this is a "must have" in my book.
Then an exact floating point type should be used as the underlying type instead of the built-in ones. Something like decimal or fixed-point or I don't know what else, anyway a type for which 1.5. == 1.5 for sure. ;-) I'm not aware of any particular class of this kind, but I suppose there should exist several C++ libraries offering this functionality.
Ok, I'll go and dig deeper. It would be nice to be able to say:
bounded_int<int, 0, 100>::type b;
std::cout << "first = " << b.first() << "\n" << "last = " << b.last() << std::endl;
Then write: std::cout << "first = " << b.constraint().lower_bound() << "\n" << "last = " << b.constraint().upper_bound() << std::endl; Note, that bounded_int<>::type is only a typedef of constrained<>. It doesn't contain first() and last(), because bounds are specific only to within_bounds constraint, while constrained<> supports any constraint. For most of other constraints first() and last() simply doesn't make sense (e.g. is_even). Best regards, Robert
participants (2)
-
Martin Dowie -
Robert Kawulak