Thread: Is my class suitable for iterator-like behavior?

Isn't a chunk of a std::string a std::string in itself rather than an iterator?

Yes, it is possible, except that next is a member function of Read whereas I would expect operator* to be overloaded for Read's iterator class. Inheriting from std::iterator is intended as a convenience so that some of the typical boilerplate can be automatically provided.

Originally Posted by Guest

Is is possible to implement something like that? And would I need to inherit from e.g. std::iterator<input_iterator_tag, std::string> (adapting all methods) for the foreach loop to work, or can I just implement from scratch the methods that I want to support (increment, deference, compare) and be done with it?

It's certainly possible. You need to implement at the least begin/end or cbegin/cend if you don't intend for the user to be able to modify whatever the iterators point to. Then in those begin and end functions, you need to return iterators. Since I assume that the entire file isn't read into memory at construction, but instead uses lazy reading, you will need some kind of iterator class. You can then choose from different iterator categories, but you should implement all the functionality in such categories. You can choose from forward only, bidirectional and random iterators. For your iterator class, you can inherit from std::iterator and it will provide the necessary boilerplate for you. You can also do it yourself. See std::iterator - cppreference.com.

Originally Posted by Elysia

(...) Since I assume that the entire file isn't read into memory at construction, but instead uses lazy reading, you will need some kind of iterator class. (...)

That's the way it is. Thanks for the guidance you two, I'll see how far I can get and post again if I get stuck.

Originally Posted by Guest

I assume the deference operator would look something like this:

Code:

std::string& ReadIter::operator*()

Most likely you should return a const reference since even if modifying the string, it will not reflect in the file. Besides, it's read iterator, and reads semantically should be const.

How would I go about accessing Read's method to get the string? Do I pass a reference to my Read object to ReadIter's constructor and store it in there? I'm not sure what the common approach is.

Yep, that's the common approach. An iterator is associated with a certain class instance. So it's typically undefined to try to compare iterators from two different objects, so it should have an instance to the object it is associated with.

Also, since Read has no "last element" as such in memory, how does the iterator know when to stop? I thought that since Read knows the number of chunks to slice the file into, maybe I could use that value to denote the last element and have the iterator keep track of its current "index" through a member? At the same time, this doesn't mesh with the iterator being constructed with a Read object. As you can see, I'm not sure how to approach this.

Iterators are positions in a file, so you can have multiple iterators from the same object and they can all be iterated without affecting each other. That means the iterator should store the necessary state, and not the parent object.
That said, for how the iterator knows to stop, this is where we're going to just have to be clever. If the read object knows how many elements there are, then an iterator could keep track of the current position and the total position.
If you don't keep track of how many objects there are, you could simply use a flag to indicate end, or some index value like -1. Then you have to use special comparison logic to ensure an iterator that has been advanced beyond the end of file compares as expected towards such a "special" iterator. It's up to you to be clever here.