Boost logo

Boost :

Subject: Re: [boost] [BGL] bundled properties and their restrictions (particularly default constructibility).
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2008-10-28 09:36:51

> 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.


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

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