Re: [Boost-users] [BGL] requirements on bundled properties

From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-03-23 13:59:17

On Mar 19, 2005, at 4:16 PM, Elvanör wrote:
> In addition to my last question, I wonder what are the type 
> requirements for the bundled properties. Because I've had quite a few 
> compiler errors, and as far as I can tell from these errors, it seems 
> to me that a type used for bundled properties must be (at least) 
> Assignable, and (that's even stranger for me) Default Constructible, 
> since I had complains about missing default constructors and member 
> references (which are not assignable).
>
> Can someone confirms this is true? If yes, this should also be 
> documented somewhere...

Yes. To be safe, I've documented that property values need to be 
Default Constructible, Copy Constructible, and Assignable, because that 
covers all of the possibilities. More explanation follows...

> ps: I have almost no idea of how a graph is stored (internally) when 
> using the BGL. But the errors seem to be linked with the type of 
> containers chosen for the vertex and out-edges list (in an 
> adjacency_list class). For example I had these errors when using vecS, 
> but if I switch to mapS, I have only the Default Constructible error 
> (not the Assignable requirement, strange...)
>
> So the bundled properties are also stored depending on the containers 
> you choose?

Yes. vecS will require at least Copy Constructible and Assignable (for, 
e.g., insertion and deletion, which must copy values). mapS will 
require Default Constructible because std::map's require Default 
Constructible value types. So, most of the requirements come from the 
underlying containers, but it's possible that other requirements (say, 
Default Constructible when using vectors) are needed for other parts of 
adjacency_list (although I can't think of any such case).

> (as for my previous question, I realised after all that, that it's 
> maybe not a good idea to have references as bundled properties, as 
> they seem to be stored in containers, and having references in 
> containers of the STL is a bad thing (because, once again, they are 
> not Assignable). Any comments?)

Using a pointer is probably better; maybe even shared_ptr if the 
objects won't necessarily outlive the graph.

        Doug