1 ++++++++++++++++++++++++++++
2 Interoperability Revisited
3 ++++++++++++++++++++++++++++
6 :copyright: Copyright Thomas Witt 2004.
8 .. Distributed under the Boost
9 .. Software License, Version 1.0. (See accompanying
10 .. file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
15 The current iterator_facade specification makes it unneccessarily tedious to
16 implement interoperable iterators.
18 In the following text a simplified example of the current iterator_facade specification is used to
19 illustrate the problem.
21 In the current specification binary operators are implemented in the following way::
23 template <class Derived>
28 template <class T1, T2>
29 struct is_interoperable :
31 is_convertible<T1, T2>
32 , is_convertible<T2, T1>
40 enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
45 return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
48 The problem with this is that operator== always forwards to Derived1::equal_to. The net effect is that the
49 following "obvious" implementation of to interoperable types does
52 struct Mutable : Facade<Mutable>
54 bool equal_to(Mutable const&);
57 struct Constant : Facade<Constant>
60 Constant(Constant const&);
61 Constant(Mutable const&);
65 bool equal_to(Constant const&);
71 c == m; // ok, dispatched to Constant::equal_to
72 m == c; // !! error, dispatched to Mutable::equal_to
74 Instead the following "slightly" more complicated implementation is necessary
76 struct Mutable : Facade<Mutable>
79 enable_if<is_convertible<Mutable, T> || is_convertible<T, Mutable>, bool>::type equal_to(T const&);
82 struct Constant : Tag<Constant>
85 Constant(Constant const&);
86 Constant(Mutable const&);
89 enable_if<is_convertible<Constant, T> || is_convertible<T, Constant>, bool>::type equal_to(T const&);
92 Beside the fact that the code is significantly more complex to understand and to teach there is
93 a major design problem lurking here. Note that in both types equal_to is a function template with
94 an unconstrained argument T. This is necessary so that further types can be made interoperable with
95 Mutable or Constant. Would Mutable be defined as ::
97 struct Mutable : Facade<Mutable>
99 bool equal_to(Mutable const&);
100 bool equal_to(Constant const&);
103 Constant and Mutable would still be interoperable but no further interoperable could be added
104 without changing Mutable. Even if this would be considered acceptable the current specification forces
105 a two way dependency between interoperable types. Note in the templated equal_to case this dependency
106 is implicitly created when specializing equal_to.
111 The two way dependency can be avoided by enabling type conversion in the binary operator
112 implementation. Note that this is the usual way interoperability betwween types is achieved
113 for binary operators and one reason why binary operators are usually implemented as non-members.
115 A simple implementation of this strategy would look like this ::
121 struct interoperable_base :
136 enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
138 , Derived2 const& rhs
141 typedef interoperable_base<
146 return static_cast<Base const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
149 This way our original simple and "obvious" implementation would
152 c == m; // ok, dispatched to Constant::equal_to
153 m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
155 The backdraw of this approach is that a possibly costly conversion of iterator objects
156 is forced on the user even in cases where direct comparison could be implemented
157 in a much more efficient way. This problem arises especially for iterator_adaptor
158 specializations and can be significantly slow down the iteration over ranges. Given the fact
159 that iteration is a very basic operation this possible performance degradation is not
162 Luckily whe can have our cake and eat it by a slightly more clever implementation of the binary
169 enable_if<is_convertible<Derived2, Derived1>, bool> operator==(
171 , Derived2 const& rhs
174 return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
181 enable_if<is_convertible<Derived1, Derived2>, bool> operator==(
183 , Derived2 const& rhs
186 return static_cast<Derived2 const&>(rhs).equal_to(static_cast<Derived1 const&(lhs));
189 Given our simple and obvious definition of Mutable and Constant nothing has changed yet. ::
191 c == m; // ok, dispatched to Constant::equal_to, m converted to Constant
192 m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
194 But now the user can avoid the type conversion by supplying the
195 appropriate overload in Constant ::
197 struct Constant : Facade<Constant>
200 Constant(Constant const&);
201 Constant(Mutable const&);
205 bool equal_to(Constant const&);
206 bool equal_to(Mutable const&);
209 c == m; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
210 m == c; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
212 This definition of operator== introduces a possible ambiguity when both types are convertible
213 to each other. I don't think this is a problem as this behaviour is the same with concrete types.
218 bool operator==(A, A);
222 bool operator==(B, B);
227 a == b; // error, ambiguous overload
232 Iterator implementations using iterator_facade look exactly as if they were
233 "hand-implemented" (I am working on better wording).
235 a) Less burden for the user
237 b) The definition (standardese) of specialized adpters might be easier
238 (This has to be proved yet)