|
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.
>
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_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk