Boost logo

Boost :

Subject: Re: [boost] [BGL] bundled properties and their restrictions (particularly default constructibility).
From: Geoff Hilton (geoff.hilton_at_[hidden])
Date: 2008-10-29 15:22:40

Andrew Sutton wrote:
>> 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)?

By restrictions I was referring to the requirements of bundled
properties as mentioned in my previous e-mails:

> 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 realize now that using the word "restrictions" is probably what
confused you, sorry about that. When I said "as specified by selectors"
I was merely stating the fact that the containers that the
boost::adjacency_list uses are specified using the selectors.

The requirements imposed on the bundled properties exist because of
requirements imposed by the containers represented by the respective
selectors (vecS for std::vector, listS for std::list, etc) in the
boost::adjacency_list type parameters OutEdgeList, VertexList, and
EdgeList (see footnote 2 of previous e-mails).

My wanting to create a custom selector (an somewhat unrelated issue
which I was mentioning as a side note) for the purposes of specifying a
custom allocator are because the graphs can and will get quite large
(read: several gigabytes of RAM in size for relatively medium-sized
graphs), the custom allocator will help ease performance bottlenecks
through preallocation of large blocks of memory.

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

A simple example of how it is currently:

template<size_t Count>
struct EdgeProperty
     boost::array<int,Count + 1> Weights;

This approach respects all bundled property requirements, however the
number of weights must be known at compilation.

struct EdgeProperty
     EdgeProperty(size_t weightCount):Weights(weightCount + 1){}

     std::vector<int> Weights;

This approach respects copy constructible and assignable, but not
default constructible. However the parameter passed in will never change
once it has been determined upon reading the graph information from the
file or database.

I don't know why I didn't think of this sooner, but something similar to
this should work for me:

struct EdgeProperty
     std::vector<int> Weights;
     static void SetInitialCount(size_t count)
         _count = count;
     static size_t _count;

This is rather hacky in that our code would only work as long as
SetInitialCount is called once before the first EdgeProperty instance is
created but oh well, whatever works!

I think that renders my question/request moot, so never mind and thanks
for listening to my rambling thought process. :)

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