C ++ Iterator Methods for a Domain

Question

Is there any reason not to include non-standard methods in the iterator in addition to the normal methods required by the iterator concept? Additional methods will be specific to the types of elements created by the iterator.

---

Specific example

To make my question more specific, I look at the menu items in the GUI menu. An iterator internally accesses a menu by index. When dereferencing, it queries the menu for the item at this index, creates an immutable object that represents the properties returned by the menu, and caches it in a member variable before returning a link to it.

Unsafe solution

An alternative was to make the view volatile and force it to write property updates back to the main menu. It will look something like this:

menu m = some_menu(); menu_iterator pos = m.begin() + 3; menu_item i = *pos; ... i.caption("foo"); i.disable(); 

This would mean that each menu_item would have to maintain its position and descriptor in the menu --- nothing special --- if there was no item in the menu inserted / removed since the creation of the item view. In this case, all kinds of hell can break, because the properties are changed for a completely different element.

The best decision?

So, my idea was to add additional methods that change the properties to an iterator rather than return values. Thus, the user always knows that the item being updated is currently pointed to, and the usual semantics of the iterator of the nested invalid names (this will not be really invalid, just point to another element).

 menu m = some_menu(); menu_iterator pos = m.begin()+3; ... pos.caption("foo"); pos.disable(); 

What do you think?

Answer 1

Here is what I will do:

• If you do not need to mutate menu items through an iterator, just solve menu_item immutable - the problem.
• If you need to be able to mutate menu items through an iterator:
  • If you have this type of control over the implementation of the main menu, make menu_item pointer to an actual menu object that will not become invalid when adding a new menu item. Perhaps you will even return to the iterator (by reference, of course) the actual menu object when dereferenced, and generally remove the wrapper menu_item .
  • If you do not have this type of control, then menu_item indeed a proxy server for the menu item, not for the menu item. Call its menu_item_proxy and document that it has proxy behavior, and that proxies become invalid when iterators become invalid. Users can still call iterator methods using the syntax pos->caption("foo") .

I would not put methods like caption() inside the iterator itself. (How to use them, say for_each ?)

Answer 2

There is nothing wrong with adding methods to an iterator. An iterator is just a special case of the visitor. the visitor must perform all necessary actions while he is visiting any object. Feel free to add any methods necessary for your business.