Boost logo

Boost Users :

From: Thomas Witt (witt_at_[hidden])
Date: 2005-03-22 14:37:42


Jens Theisen wrote:
> David Abrahams wrote:
>
>
> It is a class templated on a value_type to with implementations can be
> attached (at run time). For example:
>
> List< char > l = makeList(some_std_string) + makeList(some_char_array);
>
> l.begin(), l.end() give you an iterator which type depends solely on the
> value_type (char in this case), rather than the iterator types used as
> backends (std::string::iterator and pointers). These iterators will
> iterate over the std::string first and after this over the char array.

AFAICS it is always possible to implement a resonable operator== as long
as you apply the same restriction as for std::container iterators. I.e.
comparing iterators from different sequences yields undefined behaviour.

>
>> I don't see why that would be incompatible with forward traversal. We
>> don't even seem to have a requirement that a copy of an iterator
>> compares equal with it. Perhaps we should; then you might be in
>> trouble [Jeremy, Thomas, your thoughts?]
>
>
> Oh, you're right. I somehow assumed that would be the case. However,
> this is a requirement for Forward iterators, and iterator_faced gives
> the forward_traversal_tag to Forward traversal iterators with reference
> reference type. So it maybe a good idea to add this requirement.
>
>> That shouldn't be slow if there's plenty of inlining.
>
>
> The indirections are runtime indirections.

You can always have a fast path for comparison to the end iterator.

Regards

Thomas

-- 
Thomas Witt
witt_at_[hidden]

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net