On Sun, May 16, 2004 at 12:56:00PM -0400, christopher diggins wrote:
On Sun, May 16, 2004 at 11:07:22AM -0400, christopher diggins wrote:
On this point, I am not convinced that it is important to make this specifically a policy. I can only imagine the usage of this kind of switch for debug versus release code. Switching on a BOOST_RANGE_CHECKING
From: "Christoph Ludwig" <cludwig@cdc.informatik.tu-darmstadt.de> policy
for only some types strikes me as rather pathological.
You may be right if all the range checking policy can do is signaling an error - I am not sure. But I can imagine applications where you'd like a saturating range checking policy, i.e. the input value is replaced by the maximum or minimum valid value. Or you need a periodic behaviour where the input value is projected onto an interval.
OTOH, I may be falling into the trap of over-engineering.
You bring up a good point, but the conditional can also be introduced directly into the error policy.
It's my oversight. I didn't realize you were discussing the merits of *separate* policies for the range check and the reaction to any found violation of the range condition.
There are three options as I see it: 1) always apply check 2) have a macro as in the currrent version 3) have a separate policy for check
The arguments against number three (that I see) are: - redundancy: conditional checking can be accomplished by the error policy. - increases complexity - introduces potential errors which would be very difficult to identify and track down
It seems that the macro is not particularly attractive and could interfere with certain specialized usages of constrained types, and would be preferably dropped. Is this an accurate assesment?
I think so. Of course, any class implementing a range check policy can itself be parameterized by an error handling policy. But that's a different issue. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html