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

From: Bill Buklis (boostuser_at_[hidden])
Date: 2006-02-10 13:28:02

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).

>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.

>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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users