[boost] Re: Interval Library and comparison operators

From: Dave Gomboc (dave_at_[hidden])
Date: 2002-09-05 16:51:07

> > Judging from the variety of different, conflicting definitions that other
> > interval arithmetic libraries use, and the varied proposals that Boosters
> > have brought forth, it seems that no particular comparison operation has a
> > clearly most valid claim to operator<= and the like.  Therefore, I don't
> > think that assigning one meaning to them is appropriate: no matter the
> > definition selected, mnay users would find it counter-intuitive and expect
> > an alternate definition.  I think it would be best if all 13 relations
> > Joel Young suggested be provided (meets, precedes, etc.) and either of the
> > following done:
> > 
> >     a) prohibit definition of relational operators such as <= entirely
> >        (declare them private and do not define them)
> > or
> >     b) allow the library user to overload the relational operators
> >        as they see fit for their application (which is easily done if
> >        implementations of the 13 relations are already provided).
> 
> You missed Douglas Gregor's initial arguments in another mail.  Quoting him :

Actually, I didn't.

> > If we were to choose the former, users will write their own versions
> > of operators <, <=, >, >=, ==, !=. Inevitably, we will come across a
> > project that has two different meanings of operator< for intervals
> > (but the function signature will be the same), leading to ODR
> > violations and confused programmers.
> 
> The ODR rule is what kills you, because some applications might need more
> than one comparison policy.

I don't see the 'killing'.  If you prohibit defining operator<, the entire
problem of confusion between various possible definitions of operator<
goes away.

If you (less draconianly) leave it open for applications to define, sure,
there can be a conflict if more than one definition for the same
comparison operation is attempted, but the application writer can decide
how they want to proceed based on their own needs.  They might choose to
pick one meaning for operator<, or they might choose to not use it at all.  
I don't see the situation being confusing at all, but if it's a serious
concern, then just declare operator< privately, do not define it, and be
done with it.

Dave