Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-05 17:49:15

From: "Sylvain Pion" <pion_at_[hidden]>

> On Thu, Sep 05, 2002 at 06:13:04PM -0400, David Abrahams wrote:
> > Sure, it meets the requirements, but it doesn't give you useful
> Useful remark :)
> > If you try to put (2,4) in a map which contains (3,3), nothing will
> > I agree with others that from an STL viewpoint, lexicographic ordering
> > something like it is the only one that makes sense.
> Lexicographic ordering is fine for std::pair, because there is no
> on the kind of types you plug in (and since they are 2 different types,
> cannot compare them with each other, which doesn't let much room for
> else than lexicographic order).
> But I think it doesn't have much meaning on the intervals from the
> point of view, so I don't think it's a fine default for arithmetic

I'm not suggesting that it is. I'm only saying that you need something of
the kind for most applicationsif you want to use them as map keys. For that
reason, I'd suggest providing an appropriate compare object type which can
be passed as an argument to std::map<>.

There's also the argument that exact comparison of floating point numbers
is usually a waste of time due to rounding errors, so the application for
map keys may not be a compelling one.

> > It's not unreasonable to think of using a rel_ops approach for these
> > things, though the operators won't propagate into generic algorithms:
> >
> > namespace mine {
> > boost::interval f(boost::interval* start, boost::interval* finish)
> > {
> > using boost::intervals::my_preferred_comparison_ops;
> >
> > ... start[0] < start[1] ... ; // ok
> >
> > std::sort(start, finish); // error
> > };
> > }
> Yes, and I thought the rel_ops were usually considered evil, because they
> too general, right ?
> So they are there when you don't want them, but they are not there when
> want them :)

No, they're usually considered (by me) to be useless, since they don't
apply inside generic algorithms. Before they were nested inside
std::rel_ops they were evil.

           David Abrahams * Boost Consulting
dave_at_[hidden] *

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