HandBooks Professional Java-C-Scrip-SQL part 54 doc

Usage To start using the Operators library, implement the applicable operator(s) for your class, include "boost/operators.hpp", and derive from one or more of the Operator base classes (they have the same names as the concepts they help implement), which all reside in namespace boost. Note that the inheritance doesn't have to be public; private inheritance works just as well. In this usage section, we look at several examples of using the different concepts, and also take a good look at how arithmetic and relational operators work, both in C++ and conceptually. For the first example of usage, we'll define a class, some_class, with an operator<. We decide that the equivalence relation implied by operator< should be made available through operator==. This can be accomplished by inheriting from boost::equivalent. #include <iostream> #include "boost/operators.hpp" class some_class : boost::equivalent<some_class> { int value_; public: some_class(int value) : value_(value) {} bool less_than(const some_class& other) const { return value_<other.value_; } }; bool operator<(const some_class& lhs, const some_class& rhs) { return lhs.less_than(rhs); } int main() { some_class s1(12); some_class s2(11); if (s1==s2) std::cout << "s1==s2\n"; else std::cout << "s1!=s2\n"; } The operator< is implemented in terms of the member function less_than. The requirement for the equivalent base class is that operator< be present for the class in question. When deriving from equivalent, we pass the derived classthat is, some_classas a template parameter. In main, the operator== that is graciously implemented for us by the Operators library is used. Next, we'll take a look at operator< again, and see what other relations can be expressed in terms of less than. Supporting Comparison Operators A relational operator that we commonly implement is less thanthat is, operator<. We do so to support storage in associative containers and sorting. However, it is exceedingly common to supply only that operator, which can be confusing to users of the class. For example, most people know that negating the result of operator< yields operator>=. [1] Less than can also be used to calculate greater than, and so on. So, clients of a class supporting the less than relation have good cause for expecting that the operators that must also (at least implicitly) be supported are also part of the class interface. Alas, if we just add the support for operator< and omit the others, the class isn't as usable as it could, and should, be. Here's a class that's been made compliant with the sorting routines of the Standard Library containers. [1] Although too many seem to think that it yields operator>! class thing { std::string name_; public: thing() {} explicit thing(const std::string& name):name_(name) {} friend bool operator<(const thing& lhs, const thing& rhs) { return lhs.name_<rhs.name_; } }; This class supports sorting, and it can be stored in associative containers, but it may not meet the expectations of the client! For example, if a client needs to know whether thing a is greater than thing b, the client might write code like this: // is a greater than b? if (b<a) {} Although this is just as correct, it doesn't convey the intent of the code clearly, which is almost as important as the correctness. If the client needs to know whether a is less than or equal to b, he would have to do this: // is a less than, or equal to, b? if (!(b<a)) {} Again, the code is quite correct, but it will confuse people; the intent is certainly unclear to most casual readers. It becomes even more confusing when introducing the notion of equivalence, which we support (otherwise our class couldn't be stored in associative containers). // is a equivalent to b? if (!(a<b) && !(b<a)) {} Please note that equivalence is a different relation than equality, a topic which is expanded upon in a later section. All of the aforementioned relational properties are typically expressed differently in C++, namely through the operators that explicitly perform the tests. The preceding examples should look like this (perhaps with the exception of equivalence, but we'll let it pass for now): if (a>b) {} if (a<=b) {} if (a==b) {} The comments are now redundant, because the code says it all. As is, this code doesn't compile, because the thing class doesn't support operator>, operator<=, or operator==. But, as these operators (except operator==) can always be expressed for types that implement the less_than_comparable concept, the Operators library can help us out. All we need to do is to have thing derive from boost::less_than_comparable, like so: class thing : boost::less_than_comparable<thing> { This gives you all the operators that can be implemented in terms of operator<, and so, by just specifying a base class, the thing class now works as one would expect it to. As you can see, when deriving thing from a class in the Operators library, we must also pass thing as a template parameter to that base class. This technique is discussed in the following section. Note that operator== is not defined for classes supporting less_than_comparable, but there is another concept that we can use for that one, namely equivalent. Deriving from boost::equivalent adds operator==, but it should be duly noted that operator== is now defined in terms of an equivalence relation, which in turn does not define equality. Equivalence implies a strict weak ordering. [2] Our final version of the class thing looks like this: [2] If you're wondering what a strict weak ordering is, skip ahead to the next section, but don't forget to return here later! class thing : boost::less_than_comparable<thing>, boost::equivalent<thing> { std::string name_; public: thing() {} explicit thing(const std::string& name):name_(name) {} friend bool operator<(const thing& lhs,const thing& rhs) { return lhs.name_<rhs.name_; } }; This version only defines a single operator in thing's definition, which keeps the definition concise, and by virtue of the inheritance from less_than_comparable and equivalent, it provides quite an impressive set of useful operators. bool operator<(const thing&,const thing&); bool operator>(const thing&,const thing&); bool operator<=(const thing&,const thing&); bool operator>=(const thing&,const thing&); bool operator==(const thing&,const thing&); I'm sure you've seen many classes that provide a multitude of operators. Such class definitions can be difficult to read because there are so many operator functions declared/implemented. By inheriting from the concept classes in operators, you provide the same interface but do so more clearly and with much less code. Mentioning these concepts in the class definition makes it obvious for a reader familiar with less_than_comparable and equivalent that the class supports the aforementioned relational operations. The Barton-Nackman Trick In the two examples we've seen of inheriting from operator base classes, a strange- looking construct feeds the derived class to its base class. This is a well-known technique that is referred to as either the Barton-Nackmann trick [3] or the Curiously Recurring Template Pattern. [4] The problem that this technique solves is that of a cyclic dependency. Consider implementing a generic class that provides operator== for other classes that define operator<. Incidentally, this is a concept known as equivalent in this library (and mathematics, of course). Now, it is clear that any class utilizing an implementation providing such services needs to know about the enabling classlet's call it equivalent after the concept it helps implement. However, it's just as clear that equivalent needs to know about the class for which it should define operator==! This is a cyclic dependency, and at first glance, there's no easy way out. However, if we make equivalent a class template, and add a template parameter that designates the class for which to define operator==, we have effectively injected the dependent typewhich is the derived classinto the scope of equivalent. This example demonstrates the use of this idea. [3] "Invented" by John Barton and Lee Nackmann. [4] "Invented" by James Coplien. #include <iostream> template <typename Derived> class equivalent { public: friend bool operator==(const Derived& lhs,const Derived& rhs) { return !(lhs<rhs) && !(rhs<lhs); } }; class some_class : equivalent<some_class> { int value_; public: some_class(int value) : value_(value) {} friend bool operator<(const some_class& lhs, const some_class& rhs) { return lhs.value_<rhs.value_; } }; int main() { some_class s1(4); some_class s2(4); if (s1==s2) std::cout << "s1==s2\n"; } The base classequivalentaccepts a template argument that is the type for which it . cause for expecting that the operators that must also (at least implicitly) be supported are also part of the class interface. Alas, if we just add the support for operator< and omit the others,