On Sun, May 16, 2004 at 11:07:22AM -0400, christopher diggins wrote:
From: "Jeff Garland" <jeff@crystalclearsoftware.com>
On Sat, 15 May 2004 22:37:43 -0400, christopher diggins wrote
// you can explicitly turn off range_checking #ifdef BOOST_RANGE_CHECKING_OFF #define BOOST_RANGE_CHECKING_ON 0 #else #define BOOST_RANGE_CHECKING_ON 1 #endif
Again what happens if I want to change it for some, but not all my constrained types.
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
----- Original Message ----- From: "Christoph Ludwig" <cludwig@cdc.informatik.tu-darmstadt.de> To: <boost@lists.boost.org> Sent: Sunday, May 16, 2004 12:21 PM Subject: Re: [boost] Ranged type mini-library submission 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. 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? Christopher Diggins http://www.cdiggins.com http://www.heron-language.com