boostorg/iterator
1
0
Fork 1
mirror of https://github.com/boostorg/iterator.git synced 2025-07-24 09:57:17 +02:00
Code Issues Packages Projects Releases Wiki Activity

Doc and build fixes by Dave Abrahams.

Browse Source 
[SVN r38154]
This commit is contained in:
Thomas Witt
2007-07-06 19:47:17 +00:00
parent aa483f4961
commit c849f35965
28 changed files with 1175 additions and 8338 deletions
Download Patch File Download Diff File Expand all files Collapse all files

283
doc/interoperability-revisited.rst
View File

@ -18,86 +18,87 @@ implement interoperable iterators.
In the following text a simplified example of the current iterator_facade specification is used to
illustrate the problem.
In the current specification binary operators are implemented in the following way:
In the current specification binary operators are implemented in the following way::
template <class Derived>
struct Facade
{
};
template <class Derived>
struct Facade
{
};
template <class T1, T2>
struct is_interoperable :
or_<
is_convertible<T1, T2>
, is_convertible<T2, T1>
>
{};
template <class T1, T2>
struct is_interoperable :
or_<
is_convertible<T1, T2>
, is_convertible<T2, T1>
>
{};
template<
class Derived1
, class Derived2
>
enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
template<
class Derived1
, class Derived2
>
enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
The problem with this is that operator== always forwards to Derived1::equal_to. The net effect is that the
following "obvious" implementation of to interoperable types does not quite work.
following "obvious" implementation of to interoperable types does
not quite work. ::
struct Mutable : Facade<Mutable>
{
bool equal_to(Mutable const&);
};
struct Mutable : Facade<Mutable>
{
bool equal_to(Mutable const&);
};
struct Constant : Facade<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
...
struct Constant : Facade<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
bool equal_to(Constant const&);
};
...
Constant c;
Mutable m;
bool equal_to(Constant const&);
};
c == m; // ok, dispatched to Constant::equal_to
m == c; // !! error, dispatched to Mutable::equal_to
Constant c;
Mutable m;
Instead the following "slightly" more complicated implementation is necessary
c == m; // ok, dispatched to Constant::equal_to
m == c; // !! error, dispatched to Mutable::equal_to
struct Mutable : Facade<Mutable>
{
template <class T>
enable_if<is_convertible<Mutable, T> || is_convertible<T, Mutable>, bool>::type equal_to(T const&);
};
Instead the following "slightly" more complicated implementation is necessary
struct Constant : Tag<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
struct Mutable : Facade<Mutable>
{
template <class T>
enable_if<is_convertible<Mutable, T> || is_convertible<T, Mutable>, bool>::type equal_to(T const&);
};
template <class T>
enable_if<is_convertible<Constant, T> || is_convertible<T, Constant>, bool>::type equal_to(T const&);
};
struct Constant : Tag<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
template <class T>
enable_if<is_convertible<Constant, T> || is_convertible<T, Constant>, bool>::type equal_to(T const&);
};
Beside the fact that the code is significantly more complex to understand and to teach there is
a major design problem lurking here. Note that in both types equal_to is a function template with
an unconstrained argument T. This is necessary so that further types can be made interoperable with
Mutable or Constant. Would Mutable be defined as
Mutable or Constant. Would Mutable be defined as ::
struct Mutable : Facade<Mutable>
{
bool equal_to(Mutable const&);
bool equal_to(Constant const&);
};
struct Mutable : Facade<Mutable>
{
bool equal_to(Mutable const&);
bool equal_to(Constant const&);
};
Constant and Mutable would still be interoperable but no further interoperable could be added
without changing Mutable. Even if this would be considered acceptable the current specification forces
@ -111,44 +112,45 @@ The two way dependency can be avoided by enabling type conversion in the binary
implementation. Note that this is the usual way interoperability betwween types is achieved
for binary operators and one reason why binary operators are usually implemented as non-members.
A simple implementation of this strategy would look like this
A simple implementation of this strategy would look like this ::
template<
class T1
, class T2
>
struct interoperable_base :
if_<
is_convertible<
T2
, T1
>
, T1
, T2>
{};
template<
class T1
, class T2
>
struct interoperable_base :
if_<
is_convertible<
T2
, T1
>
, T1
, T2>
{};
template<
class Derived1
, class Derived2
>
enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
typedef interoperable_base<
Derived1
, Derived2
>::type Base;
template<
class Derived1
, class Derived2
>
enable_if<is_interoperable<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
typedef interoperable_base<
Derived1
, Derived2
>::type Base;
return static_cast<Base const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
return static_cast<Base const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
This way our original simple and "obvious" implementation would work again.
This way our original simple and "obvious" implementation would
work again. ::
c == m; // ok, dispatched to Constant::equal_to
m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
c == m; // ok, dispatched to Constant::equal_to
m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
The backdraw of this approach is that a possibly costly conversion of iterator objects
is forced on the user even in cases where direct comparison could be implemented
@ -158,70 +160,71 @@ that iteration is a very basic operation this possible performance degradation i
acceptable.
Luckily whe can have our cake and eat it by a slightly more clever implementation of the binary
operators.
operators. ::
template<
class Derived1
, class Derived2
>
enable_if<is_convertible<Derived2, Derived1>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
template<
class Derived1
, class Derived2
>
enable_if<is_convertible<Derived2, Derived1>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived1 const&>(lhs).equal_to(static_cast<Derived2 const&(rhs));
}
template<
class Derived1
, class Derived2
>
enable_if<is_convertible<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived2 const&>(rhs).equal_to(static_cast<Derived1 const&(lhs));
}
template<
class Derived1
, class Derived2
>
enable_if<is_convertible<Derived1, Derived2>, bool> operator==(
Derived1 const& lhs
, Derived2 const& rhs
)
{
return static_cast<Derived2 const&>(rhs).equal_to(static_cast<Derived1 const&(lhs));
}
Given our simple and obvious definition of Mutable and Constant nothing has changed yet.
Given our simple and obvious definition of Mutable and Constant nothing has changed yet. ::
c == m; // ok, dispatched to Constant::equal_to, m converted to Constant
m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
c == m; // ok, dispatched to Constant::equal_to, m converted to Constant
m == c; // ok, dispatched to Constant::equal_to, m converted to Constant
But now the user can avoid the type conversion by supplying the appropriate overload in Constant
But now the user can avoid the type conversion by supplying the
appropriate overload in Constant ::
struct Constant : Facade<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
...
struct Constant : Facade<Constant>
{
Constant();
Constant(Constant const&);
Constant(Mutable const&);
bool equal_to(Constant const&);
bool equal_to(Mutable const&);
};
...
c == m; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
m == c; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
bool equal_to(Constant const&);
bool equal_to(Mutable const&);
};
c == m; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
m == c; // ok, dispatched to Constant::equal_to(Mutable const&), no conversion
This definition of operator== introduces a possible ambiguity when both types are convertible
to each other. I don't think this is a problem as this behaviour is the same with concrete types.
I.e.
I.e. ::
struct A {};
struct A {};
bool operator==(A, A);
bool operator==(A, A);
struct B { B(A); };
struct B { B(A); };
bool operator==(B, B);
bool operator==(B, B);
A a;
B b(a);
A a;
B b(a);
a == b; // error, ambiguous overload
a == b; // error, ambiguous overload
Effect
======