This is just a bump of sorts, I'm still very much in need of a reply. Note, in [2], I meant the boost.user list, not boost.devel.
Geoff, Sorry I missed this, my mail filter didn't pick up the BGL subject... 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
I'm not entirely sure what restrictions you're referring to with regard to the selectors... that the containers within your bundled properties are grown at run time (as with a list or vector) or fixed at compile time (as with array)? In general, the selectors have a little to do with vertex/edge properties (including bundles) as possible, so the impact on generic algorithms is probably negligible - unless you're doing something interesting like parallel or distributed graphs. My feeling is that if you're considering building your own selector, then you may be over-thinking the problem. Of course, I could also be completely misunderstanding the point of your question. Is there any way to give an example of what you're trying to do? Andrew Sutton andrew.n.sutton@gmail.com