iterator semantics

What category would an iterator be that can be incremented and decremented (and in theory random access would be possible too!), but the return values can't be assigned to.

I'm writing an iterator over registry keys. The value_type of the iterator is reg_key (a class representing a registry key). I have no concrete objects to return! The objects are actually created as I go ahead. Only input iterators allow this AFAIK. Maybe not even those.

I can add a member of reg_key and return a reference to this. But this object changes. It might go invalid too soon if the caller stores a reference.

Any ideas?

A read-only iterator implies that it's constant. I don't see anything wrong with only providing a constant iterator.

After reading your post a few more times, it sounds like you're looking for some design guidance on how to make the iterator writable, which would result in a registry key being modified based on that write/access - correct?

>> The objects are actually created as I go ahead.
That's fine, as long as the rest of your design accommodates for this.

>> It might go invalid too soon if the caller stores a reference.
Then don't return a reference, return a copy. After all, it's the registry that you want to modify in the end.

Is there anything inparticular in STL that you want you interators to be compatible with? Something out of <algorithm> perhaps?

gg

Quote:

---

A read-only iterator implies that it's constant. I don't see anything wrong with only providing a constant iterator.

---

A const iterator is supposed to return "const T&" from operator* and "const T*" from operator->. I don't want these references to be const, it should be possible to modify the underlying object. Or maybe I could use const anyway, since the object itself isn't modified, just the key it represents. Hmmm...
It just shouldn't be possible to assign to it.

Quote:

---

After reading your post a few more times, it sounds like you're looking for some design guidance on how to make the iterator writable, which would result in a registry key being modified based on that write/access - correct?

---

No, I want the underlying objects to modify the registry, but the objects themselves to be immutable.

Quote:

---

Then don't return a reference, return a copy. After all, it's the registry that you want to modify in the end.

---

Can't return a copy from operator->.

Quote:

---

Is there anything inparticular in STL that you want you interators to be compatible with? Something out of <algorithm> perhaps?

---

Not any particular algorithms except perhaps foreach and copy.

I don't understand why you feel the need to constrain your design to the exact semantics of an STL iterator.

>> No, I want the underlying objects to modify the registry
That's what I meant...accessing the iterator via *it or it->

>> ,but the objects themselves to be immutable.
Then return an object that only provides methods for reading and writting the registry key it represents. You can return a copy of this object so you don't have to worry about references being invalid too soon.

STL iterators use reference semantics so you can modify existing objects within a container.
The "objects" you wish to modify aren't on the stack or heap, they're in the registry.

You can use these iterators in foreach<> and you could overload operators to make copy<> to something special (like duplicate an enrite hive in the registry - which would be cool).

gg

Thanks for your input. I've decided to give the reg_key and reg_value objects (the value_type of reg_key_iterator and reg_value_iterator) a copy constructor, but a private assignment operator. This way, you cannot assign to an existing reg_key but you can create a copy.

It does what I want it to. I just wonder if I claim too much by giving it a bidirectional iterator tag.

>> I just wonder if I claim too much by giving it a bidirectional iterator tag.
Never tried decrementing the index when calling RegEnumKeyEx()...is that what you do when you "it--"?

gg

It works, I know it. I just wonder if it makes sense.

Does it meet these requirements?

See also: trivial iterator.

gg

Thanks for this. It is indeed a immutable bidirectional iterator. :)