|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-18 22:32:40
----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> As for combining them - the "iterator adaptors" could benefit from using
> "operators" templates to simplify their implementation, but in the rest
they
> are quite different. BTW, is there a reason why they don't use the
library? I
> could think of at least two possible reasons - undesirable dependency
or/and
> heaviness of the "operators". Is it so?
Because the operators templates instantiate operator functions even though
they are not used, the corresponding operators must be defined on the
underlying iterators. For example, a bidirectional iterator does not support
operator-(). This leads to a much more complex design that requires
distinguishing iterator adaptors for all the iterator categories. An early
revision by Jeremy of my original design worked this way, but I later
convinced him that it wasn't worth the complexity. BTW, I think the
"implementation notes" in the documentation at the end no longer applies,
right, Jeremy?
Implementation Notes
The code is somewhat complicated because there are three iterator adaptor
class: forward_iterator_adaptor, bidirectional_iterator_adaptor, and
random_access_iterator_adaptor. The alternative would be to just have one
iterator adaptor equivalent to the random_access_iterator_adaptor. The
reason for going with the three adaptors is that according to 14.5.3p5 in
the C++ Standard, friend functions defined inside a template class body are
instantiated when the template class is instantiated. This means that if we
only used the one iterator adaptor, then if the adapted iterator did not
meet all of the requirements for a RandomAccessIterator then a compiler
error should occur. Many current compilers in fact do not instantiate the
friend functions unless used, so we could get away with the one iterator
adaptor in most cases. However, out of respect for the standard this
implementation uses the three adaptors.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk