"I believe that iterator theories are as central to Computer Science as theories of rings or Banach spaces are central to Mathematics." -- An Interview with A. Stepanov http://www.stlport.org/resources/StepanovUSA.html <http://www.stlport.org/resources/StepanovUSA.html> that's just the tip of the ice berg, i found that interview to be a real eye opener having been through university where only OO programming got extensive coverage. Always seemed odd to me that what is such a big thing in the C++ community seems to get such a 'bad deal'. I hear things are changing though ... </ramble> gaz -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jim Lear Sent: 14 December 2004 16:30 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Re: Iterators and maps [was Re: Where should STL suggestionsgo?] David Abrahams wrote: Jim Lear wrote: 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; } Am I just too ignorant to make any sense? :-) Maybe I'll crawl back into my hole. :-) You're making sense, but consider this: why should the map get involved in that operation at all when you can do it all with the iterator? Seems like a design flaw to get another object involved needlessly. Not only might it be a design flaw, but it may invite inefficiency. But really it's just consistency with other languages which iterate over the keys (like awk) and code clarity. Someone unfamiliar with STL would find the following obvious: for (m_type::iterator i=m.begin();...) for (mi_type::iterator j=m[i].begin();...) cout << m[i][j] << endl; But they may find for (m_type::iterator i=m.begin();...) for (mi_type::iterator j=i->second.begin();...) cout << j->second << endl; obtuse. Perhaps folks intimately familiar with iterators may find this is hard to believe. :-) An alternative question might be, why should one who uses maps and vectors also be required to be familiar with the intricacies of iterators? To me, that seems like a design flaw. I have never encountered another language that requires the user to understand iterators to the extent STL does. Ease of use and learning ought to be a priority in the design of these objects, to the extent it is efficient and safe. To use iterators in lieu of keys or indices seems to me like a great simplification for users. It completely obviates the need to understand iterators in this case (while still allowing existing iterator functionality). -- Jim Lear