Boost logo

Boost :

Subject: [boost] [BGL] bundled properties and their restrictions (particularly default constructibility).
From: Geoff Hilton (geoff.hilton_at_[hidden])
Date: 2008-10-23 12:34:55

Hi, my graph uses bundled properties for both vertices and edges. Both
bundled properties have containers that must be of a certain size when
they're actually used. For testing purposes these containers were of
fixed size (underlying container is currently a boost::array<..>.

However the real world dictates that the size of these containers pretty
much must be determined at run-time as opposed to compile-time because
the graph is built using an external source such as a file or database
for example.

I know the documentation requires that bundled properties be all of
default constructible, assignable and copy constructible[1][2] because
of how the containers (as specified by selectors) store them. I'm unsure
as to whether or how this may effect algorithms provided by the BGL, so
far the only ones I've used are dijkstra_shortest_path and

Given that a custom container selector may be created and push/erase
must be overloaded for the given custom container (for my purposes, this
would be to specify a custom allocator as in the example)[3], how safe
would it be to say that the container selector entirely dictates the
restrictions in question?

If the answer is "very", presuming we weren't to change these
restrictions for existing provided selectors would it be possible for an
explicit exception to be made for custom containers and their selectors
(created using boost::container_gen<>)? This exception might say that
the restrictions in question are then dictated by the custom container.
I figure this shouldn't affect existing user code since the current
restrictions are already at their most strict.

Thanks very much,

[2] Doug Gregor 23/03/2005, this list.

Boost list run by bdawes at, gregod at, cpdaniel at, john at