Boost logo

Boost :

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]


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk