Re: [boost] Ranged type mini-library submission

From: Christoph Ludwig (cludwig_at_[hidden])
Date: 2004-05-16 12:41:30

On Sun, May 16, 2004 at 12:56:00PM -0400, christopher diggins wrote:
> From: "Christoph Ludwig" <cludwig_at_[hidden]>
> > 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
> 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