Boost.Graph folks, I just committed a raft of changes to the the property_map library in the v2 branch. I also broke source compatibility with it. Since Boost.Graph is really the only client (according to a grep on all headers in Boost), I'm not terribly worried. I figure I'll be propagating all of these changes anyway... I may end up branching the 'pending' directory also since there are some references to the property library with in it. Basically, I wanted to explode the single header into a number of files within a property_map library - it makes adding new property maps a little easier when you're not thru a couple thousand lines for a single function :) It also turns out that most files don't need to include the archetypes or concepts unless there's actually a concept check, so it can cut out some code. This also allows other libraries to selectively pick and choose which maps to work with. I started working on a ChangeLog that should help document the more destructive changes. It's here: http://svn.boost.org/trac/boost/browser/sandbox/graph-v2/libs/ property_map/ChangeLog It turns out that many of the property maps (especially, identity, dummy) provide far more interface than they should - especially the lvalue access (via operator[]). I'm not really sure if lvalue access conceptually applies in all of these cases. My rule of thumb is: if there's something that can be returned by reference, do it. If there's something that can be returned by const reference, do that. Otherwise, do nothing. This means, for example, that the dummy_property_map no longer does everything it used to, it simply consumes writes, but should do so more efficiently than before (it no- ops the put() function). Umm... If anybody is interested in perusing the source, I'd appreciate it. If anybody feels that I should add or remove anything (like dynamic_properties?) please let me know. Andrew Sutton asutton@cs.kent.edu