Jim Lear wrote: <snip>
I'm a little overwhelmed by these discussions, so forgive me for my ignorance or incapacity to communicate. My intention isn't to create container-independent code.
Ah, good.
My intention is to create code for maps (and vectors) that looks like what I think code for maps (and vectors) would look like. Iterators look to me like pointers to linked lists for vectors, and like pairs of pointers for maps.
Iterators are kind of like pointers into arrays, but possibly with some limitations on how you can use them; random-access iterators have no such limitations, whereas input and output iterators only allow you to go through the sequence once, forward, one step at a time. Iterators over maps are bidirectional iterators, which are somewhere in-between: they can then be moved forward and backward over the sequence however many times you want, but only one step at a time. They do not behave like pairs of pointers but like pointers to pairs. (The standard iterator categories unfortunately combine requirements on traversal operations with requirements on access operations; if you want to know exactly what the iterator categories mean, look elsewhere.)
There is nothing wrong with these semantics, except they seem odd compared to some other languages semantics for associative arrays (e.g. awk). However, overloading the operator[] in the map class to take iterators as a parameter would allow iterators to be treated like keys, if one desires, which to me seems more natural. This would still allow one to iterate over keys, mapped values, or pairs.
So in the absolute most abhorently poor code example (let's just call it "meta-code"), the map operator would behave like:
data_type &operator[](const iterator &i) { return i->second; }
I think that code should actually work if you only replace "data_type" to "mapped_type", but I suggest you don't go editing your <map> header just yet!
Am I just too ignorant to make any sense? :-) Maybe I'll crawl back into my hole. :-)
No, but I think your concept of what an iterator is may be faulty. Since an iterator "points" to a sequence element (or to the end of a sequence) by itself; there is no need to combine it with a container to access that element. You seem to want a regularity which doesn't really make sense, hence my earlier guess that you wanted to write container- independent code. Ben.