[boost] [graph] [property_map] updates

From: Andrew Sutton (asutton_at_[hidden])
Date: 2007-09-04 14:22:19

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_at_[hidden]