
I'd like to know a little more about the design rationale for property maps, specifically the (maybe implicit) decision not to overload operator[] with respect to constness. The design leads to a situation that is, in some respects, at odds with convention. The most obvious point of conflict is put_get_helper. In fact, I wouldn't be surprised if the decision not to overload operator[] was simply a consequence of writing put_get_helper. (Pure speculation.) template<class Reference, class PropertyMap> struct put_get_helper { }; template<class R, class P, class K> R get( put_get_helper<R,P> const& map, K const& key ); template<class R, class P, class K, class V> void put( put_get_helper<R,P> const& map, K const& key, V const& value ); In contrast with standard containers, the constness of the property map isn't correlated to the constness of its elements. I wonder why the above wasn't written as template<class Reference, class PropertyMap, class ConstReference> struct put_get_helper { }; template<class R, class P, class C, class K> R get( put_get_helper<R,P,C>& map, K const& key ); template<class R, class P, class C, class K> C get( put_get_helper<R,P,C> const& map, K const& key ); template<class R, class P, class C, class K, class V> void put( put_get_helper<R,P,C>& map, K const& key, V const& value ); Another point of conflict is the property_map traits class, with its nested 'type' and 'const_type'. Doesn't convention suggest that 'type const' is the appropriate type for a non-mutable property map? My initial statement was that the design leads to a situation that is *in some respects* at odds with convention. When property maps are viewed, not as first class containers of their data, but as having more-or-less the same status as container iterators, the situation clarifies. I suppose that must have been the author's intent. // A deficient, but harmless implementation of put(), get() for iterators. template<class Reference, class Iterator> struct put_get_helper { }; template<class R, class I, class K> R get( put_get_helper<R,I> const& it, K const& key ); template<class R, class I, class K, class V> void put( put_get_helper<R,I> const& it, K const& key, V const& value ); // Parallel to property_map. template<class Container> struct container_iterator { typedef typename Container::iterator type; typedef typename Container::const_iterator const_type; };

On Mar 5, 2006, at 3:19 PM, Daniel Mitchell wrote:
My initial statement was that the design leads to a situation that is *in some respects* at odds with convention. When property maps are viewed, not as first class containers of their data, but as having more-or-less the same status as container iterators, the situation clarifies. I suppose that must have been the author's intent.
I believe that was the intent. Property maps have shallow copying semantics (like pointers and iterators), which often (but not always <g>) implies that the constness of the data is not based on constness of the type referencing the data. Doug
participants (2)
-
Daniel Mitchell
-
Douglas Gregor