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
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<key,void*> 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. 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). maintain.
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.
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. What do you think? Anyone else have any thoughts on this?
I could thus add another pair of typedefs for this case. How does
void_ptr_map_reference void_ptr_map_const_reference
sound? Is it worth the effort?
As for the typedef, I'm honestly not sure if it's worth it or not. My goal for typedefs (and I'm sure it is similar with most people) is that: A: it makes the code more readable B: it's shorter (a.k.a. less typing) Using "void_ptr_map_reference", etc. falls in line with exposing details more. Maybe it's worthwhile. Maybe it's not. I'm not sure. Personally it's not a big deal for me typing std::pair<key,void*>. The readability tradeoff seems about the same - maybe even leaning toward using the pair directly. I think I'll defer to someone else's opinion on this one. -- Bill --
-----Original Message-----
Out of curiosity, if nothing else, is there a corresponding typedef that would match this? std::map would use value_type. What would be the equivalent for the ptr_map/void-ptr-map? Of course, depending on the length and indirection, it may be better anyway to explicitly list it out as the std::pair.
The current docs are a bit weak in this matter. But
ptr_map<Key,T>::value_type is T*
ptr_vector<T>::value_type is T*
The fact that you cannot use the normal iterator to access the key in an algorithm is of course bad when you need it, but I still feel that the design in general is OK given the domain.
There is no nested typedef right now that would give you the value-type of the void-ptr-map used internally, though you are guaranteed that it is std::map<Key,void*>.
I could thus add another pair of typedefs for this case. How does
void_ptr_map_reference void_ptr_map_const_reference
sound? Is it worth the effort?
-Thorsten
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users