Boost logo

Boost :

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-05 14:23:53

On Thu, Sep 05, 2002 at 12:49:46PM -0600, Dave Gomboc wrote:
> > > 1) Don't support any comparison operators, or
> > > 2) Use comparison policies
> >
> > 3) Pick a fixed meaning for the comparison operators, and provide
> > function (object)s for the other kinds of comparison.
> 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 :

> It seems there are really only two options here:
> 1) Don't support any comparison operators, or
> 2) Use comparison policies
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at