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 dag_shortest_path. 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, Geoff [1] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.htm... [2] Doug Gregor 23/03/2005, this list. [3] http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/using_adjacency_list.htm...