BGL: a quick question on bundled properties and graph traits

Elvanör

14 Mar 2005 14 Mar '05

11:55 p.m.

Hello, How can I get the type of my vertex properties if I use bundled properties as internal properties? My example is this one: typedef adjacency_list Graph; // and in one function: template <class graph> void myFunction (Graph & g) { // Here I need to declare an object of type myClass... how can I get this type using graph_traits ?? } Thanks. Again, the documentation on bundled properties really need to be improved, IMHO. All the information I could find was relevant to the old property maps mechanism... Jean-Noël

Attachments:

attachment.bin (text/enriched — 640 bytes)

Show replies by date

Elvanör

17 Mar 17 Mar

1:10 a.m.

New subject: BGL: a quick question on bundled properties and graph traits

Since nobody answered my first question, I had to look up myself on the code and found some kind of answer (at least, it works for me). I just use, if I have a graph of type Graph (it is in fact an adjacency list, but that is unimportant), typedef typename Graph:vertex_bundled VertexType; But I am still wondering if it is the "correct solution". For me it works, however I don't understand why I use directly Graph:vertex_bundled and not some kind of graph_traits<Graph>::vertex_bundled thing... I am new to traits (be it for STL iterators or Boost Graphs ) and don't understand how it works internally (I just understand the basic concept yet, and know how to use them). What is the whole purpose of having a graph_traits class if something as simple as Graph:vertex_bundled works? Why am I doing things like graph_traits<Graph>::vertex_descriptor instead of just Graph::vertex_descriptor then ?? Any help would be appreciated, and I still think the documentation should mention how to get the type of the bundled properties. Jean-Noël Rivasseau

...

Hello,

How can I get the type of my vertex properties if I use bundled properties as internal properties?

My example is this one:

typedef adjacency_list Graph;

// and in one function:

template <class graph>

void myFunction (Graph & g) {

// Here I need to declare an object of type myClass... how can I get this type using graph_traits ??

}

Thanks. Again, the documentation on bundled properties really need to be improved, IMHO. All the information I could find was relevant to the old property maps mechanism...

Jean-Noël _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Douglas Gregor

18 Mar 18 Mar

4:33 a.m.

New subject: BGL: a quick question on bundled properties and graph traits

On Mar 16, 2005, at 8:10 PM, Elvanör wrote:

...

I just use, if I have a graph of type Graph (it is in fact an adjacency list, but that is unimportant),

typedef typename Graph:vertex_bundled VertexType;

But I am still wondering if it is the "correct solution". For me it works, however I don't understand why I use directly Graph:vertex_bundled and not some kind of graph_traits<Graph>::vertex_bundled thing...

Because I was lazy :) We really should have "vertex_bundle_type<Graph>::type" and "edge_bundle_type<Graph>::type" traits, which are defined for graphs that have bundled properties.

...

I am new to traits (be it for STL iterators or Boost Graphs ) and don't understand how it works internally (I just understand the basic concept yet, and know how to use them). What is the whole purpose of having a graph_traits class if something as simple as Graph:vertex_bundled works? Why am I doing things like graph_traits<Graph>::vertex_descriptor instead of just Graph::vertex_descriptor then ??

The reason that we use graph_traits<Graph>::foo instead of Graph::foo is that you can add graph_traits<Graph>::foo even if you can't change the type Graph. If we always relied on having a member type "foo", we'd always have to change the graph type to put that type "foo" in. Check out, for instance, the vector_as_graph module: it makes a vector of edge lists into a graph, without changing the vector at all. graph_traits makes that possible.

...

Any help would be appreciated, and I still think the documentation should mention how to get the type of the bundled properties.

You're absolutely correct. I've just added the aforementioned traits with some documentation for them (within the description of bundled properties). Doug

Elvanör

19 Mar 19 Mar

12:17 a.m.

New subject: BGL: a quick question on bundled properties and graph traits

Hi.

...

...
Any help would be appreciated, and I still think the documentation should mention how to get the type of the bundled properties.

You're absolutely correct. I've just added the aforementioned traits with some documentation for them (within the description of bundled properties).

I guess all of this is in the CVS, of course... I wondered also if there was a way to download all of the boost documentation (HTML format) for offline browsing, rather than going to the web site every time (maybe this is intentionalk though). I mean, a way different than downloading the CVS documentation. I have yet a new question: is it possible to have, as a bundled property, references to objects and not just the object themselves ? IE, typedef adjacency_list Graph; works, but I can't manage to have: typedef adjacency_list Graph; (A pointer, though, is ok as I have noted on one of my earlier mails). I have noted, though, that function such as add_vertex(const VertexProperties& p, adjacency_list& g) do take a reference to a VertexProperties. So should I assume that if I construct my graph in this way (via use of add_vertex, etc...) my bundled properties will just be references, ie, no copy construction will occur ( and after running my graph algorithms, the modifications on the bundled properties will still be accessible)? Jean-Noël

Elvanör

9:16 p.m.

New subject: [BGL] requirements on bundled properties

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... Jean-Noël Rivasseau 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? (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?)

...

Hi.

...
...
Any help would be appreciated, and I still think the documentation should mention how to get the type of the bundled properties.

You're absolutely correct. I've just added the aforementioned traits with some documentation for them (within the description of bundled properties).

I guess all of this is in the CVS, of course... I wondered also if there was a way to download all of the boost documentation (HTML format) for offline browsing, rather than going to the web site every time (maybe this is intentionalk though). I mean, a way different than downloading the CVS documentation.

I have yet a new question: is it possible to have, as a bundled property, references to objects and not just the object themselves ?

IE,

typedef adjacency_list Graph;

works, but I can't manage to have:

typedef adjacency_list Graph;

(A pointer, though, is ok as I have noted on one of my earlier mails).

I have noted, though, that function such as add_vertex(const VertexProperties& p, adjacency_list& g) do take a reference to a VertexProperties. So should I assume that if I construct my graph in this way (via use of add_vertex, etc...) my bundled properties will just be references, ie, no copy construction will occur ( and after running my graph algorithms, the modifications on the bundled properties will still be accessible)?

Jean-Noël

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Doug Gregor

23 Mar 23 Mar

6:59 p.m.

New subject: [BGL] requirements on bundled properties

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

7172

Age (days ago)

7181

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Doug Gregor
Douglas Gregor
Elvanör