[boost] Re: boost::operators -> boost::iterator_ops ?

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-11-28 17:15:39

> Dave Abrahams writes:
>  > Duh. Or as my lovely wife would say, "crippity crap!" Is there something we
>  > can do to force people to implement it when they derive from the random
>  > access helper? Perhaps using the concept_checks technique would work.
>
> Well, operator- is a funny case because it is not used inside of the
> helper (or any of the other operators), so there isn't a good reason
> to check for it there (though an algorithm that depends on operator-
> should use concept checks).

Except that if you don't have a random access iterator unless op- is
supported. Whether an algorithm chooses to make use of op- is an
implementation detail. If you give an iterator's traits the tag
random_access_iterator_tag, but you don't define op-, you're essentially
lying to whatever library is going to use the traits.

> But your point is a good one in general. The operators should use
> concept checks to try to improve the error messages that occur
> when the core operations are not there. Here's an example:
>
> template <class T, class U = T>  // = T really is needed; not a coding error
> class less_than_comparable
> {
>      __STL_CLASS_REQUIRES_BINARY_OP(_OP_LESS_THAN, T, U);
>      __STL_CLASS_REQUIRES_BINARY_OP(_OP_GREATER_THAN, U, T);
>
>      friend bool operator<=( const T& x, const U& y ) { return !(x > y); }
>      friend bool operator>=( const T& x, const U& y ) { return !(x < y); }
>      friend bool operator>( const U& x, const T& y )  { return y < x; }
>      friend bool operator<( const U& x, const T& y )  { return y > x; }
>      friend bool operator<=( const U& x, const T& y ) { return !(y < x); }
>      friend bool operator>=( const U& x, const T& y ) { return !(y > x); }
> };

That would be an improvement, but only inasmuch as it improves the error
messages you get. As it stands, if you try to derive from
less_than_comparable and you haven't defined op<, your program is ill-formed
and you WILL get a diagnostic.

One possible solution to my problem: have the random access helper define a
friend function (never called) which calls op- on a pair of const T&, and
somehow ensures that the result has the appropriate difference_type. I'm
sure we can come up with an answer to that last missing detail.

Also, FWIW, there is no need to publicly derive from things like addable. It
doesn't hurt, but it does add clutter.

-Dave