A simple question about iterator category.

[Steve H]

From "C++ Programming Language (3rd Edition)" I understand that there
are 5 standard iterator categories defined in the "std" namespace:

Output *p= p++
Input =*p -> ++ == !=
Forward =*p -> *p= ++ == !=
Bidirectional =*p -> *p= ++ -- == !=
Random Access =*p -> *p= ++ -- == != + - += -= < > <= >=

I have an iterator-like class for which I would like to ensure
compatibility with 3rd party algorithms which target STL containers –
hence I suspect it a good idea to define a typedef for
iterator_category. My confusion is that the iterator operations I can
support are { ->; *p=; ++; --; ==; != } There is no way for me to
define =*p as modification of stored values is precluded by
implementation strategy.

Would it be appropriate to typedef bidirectional_iterator_tag as
iterator_category in the definition of my iterator-like class - and
supply a definition only for const_iterator in order to preclude the
expectation of operations like =*p? Is this the neatest way to
implement a bi-directional read-only iterator in order to interact
most effectively with existing algorithms?

Thanks,

Steve

 

[Howard Hinnant]

From "C++ Programming Language (3rd Edition)" I understand that there
are 5 standard iterator categories defined in the "std" namespace:

Output *p= p++
Input =*p -> ++ == !=
Forward =*p -> *p= ++ == !=
Bidirectional =*p -> *p= ++ -- == !=
Random Access =*p -> *p= ++ -- == != + - += -= < > <= >=

I have an iterator-like class for which I would like to ensure
compatibility with 3rd party algorithms which target STL containers –
hence I suspect it a good idea to define a typedef for
iterator_category. My confusion is that the iterator operations I can
support are { ->; *p=; ++; --; ==; != } There is no way for me to
define =*p as modification of stored values is precluded by
implementation strategy.

Would it be appropriate to typedef bidirectional_iterator_tag as
iterator_category in the definition of my iterator-like class - and
supply a definition only for const_iterator in order to preclude the
expectation of operations like =*p? Is this the neatest way to
implement a bi-directional read-only iterator in order to interact
most effectively with existing algorithms?

Probably.

I know that's a very unsatisfying answer, but it is the best one I have
for now.

The current iterator categories confuse traversal properties with access
properties. We hope to do a better job in the next C++ standard (C++0X).

Most algorithms (statically) branch based on traversal properties.
However most is not all, and I'm currently aware of at least one
implementation of one std::algorithm that branches on the current
iterator categories for the reason of access, not traversal.

All that being said, your strategy is likely to work most of the time,
and when it fails, it is likely to do so at compile time instead of run
time (which is a good thing).

-Howard