Re: [Boost-users] [ptr_container] ptr_map predicates

Bill Buklis wrote:

The design of the normal iterator is beautiful. I much prefer it this way, i.e. using it as if it were a pointer to the object. The downside, of course, was just when you do need a key/value iterator. Since it can be done using the pair and base() iterator, perhaps that is sufficient and no changes need to be made.

However, from a purely design perspective (as opposed to usage), the only problem I see with that is that it exposes the internal workings of the class a little (I try to keep my classes as "black box" as possible. It's not always feasible, but at least that's the initial goal). The only way around that I can see at the moment is to have two types of iterators offered by the class - the normal iterator (same as it is now) and a "map_iterator" which acts the same as a std::map iterator would.

you mean iterating over pair or pair ?

I'm not sure how feasible that would be to implement. I haven't studied the inner workings of the ptr_map class that much (although I'm quickly learning more and more about it).

it's certainly doable, probably with a little overhead to create a proxy.

...

From a user's perspective all you care about is that it is relatively easy to use, that you can get it do what you want, and it's not too difficult to maintain.

right.

...

From an aesthetics standpoint, it would be nice to have the two types of iterators depending on what you need. The code would be more readable. It would also shut those up who complain about the iterators not acting like std::map. "Look, use map_iterator if you want that!" Also in those cases where you do need both the key and the value, you wouldn't have to cast the void* back to the correct object type.

yeah, that is bad.

Unless I'm mistaken this whole argument only pertains to ptr_map and ptr_multimap. The other classes only have a single value, so the iterators already act like the standard versions.

true.

What do you think?

I'm leaning towards a new iterator type that iterators over pair. -Thorsten