[graph] [serialization] serialized descriptors
Hello, there is utility code for serializing an adjancency_list graph to an archive in the BGL. But I wonder about two things: 1) I have a list of descriptors in my program. This list is a selection of vertices. If I want to serialize my program's states, I need to serialize the graph as well as this selection. This means I have to serialize references to vertices. Now AFAIK I cannot simply serialize descriptors, because they essentially are pointers. I need a persistent ID. Is there existing functionality for this? If not, I have to either use one of the vertex properties as ID, or autogenerate IDs (for example, by using casting the descriptors to an intptr_t and using this value as ID) and upon deserialization use these for mapping the right descriptors back into the list. 2) One vertex property is a map of boost::any values. map < string, any
to be exact. Does the BGL serialize the properties? If so, how does it deal with boost::any constructs?
1) I have a list of descriptors in my program. This list is a selection of vertices. If I want to serialize my program's states, I need to serialize the graph as well as this selection. This means I have to serialize references to vertices. Now AFAIK I cannot simply serialize descriptors, because they essentially are pointers. I need a persistent ID. Is there existing functionality for this? If not, I have to either use one of the vertex properties as ID, or autogenerate IDs (for example, by using casting the descriptors to an intptr_t and using this value as ID) and upon deserialization use these for mapping the right descriptors back into the list.
It depends on the serialization method. Are you using the Boost Serialization library or one of the Boost.Graph I/O functions like write_graphviz()? It's been a while since I looked closely at the graph code, so take this with a grain of salt. Some versions of the adjacency list actually have implicit ids. If you declare the adjacency list with vector storage for vertices, then you can simply create an id property map over the vertices. The reason for this is that vecS causes the vertex descriptor to be the index into the vector, rather than a pointer. For any other vertex storage option, you're on your own.
You should probably also steer clear of the older properties (boost::property<>) for graphs. I would recommend defining vertex and edge structures that contain all the features you need for your graph application and then attaching property maps to them. You may end up having to assign your own unique id's (which could actually be strings) , but at least you'll know how it's going to work. Andrew Sutton asutton@cs.kent.edu
Hi,
It depends on the serialization method. Are you using the Boost Serialization library or one of the Boost.Graph I/O functions like write_graphviz()?
Boost.Serialization.
It's been a while since I looked closely at the graph code, so take this with a grain of salt. Some versions of the adjacency list actually have implicit ids. If you declare the adjacency list with vector storage for vertices, then you can simply create an id property map over the vertices. The reason for this is that vecS causes the vertex descriptor to be the index into the vector, rather than a pointer. For any other vertex storage option, you're on your own.
Interesting, unfortunately I cannot use vecS, since I add/remove a lot, which would render iterators and descriptors invalid with vecS. So it is as I expected - I have to do it manually.
You should probably also steer clear of the older properties (boost::property<>) for graphs. I would recommend defining vertex and edge structures that contain all the features you need for your graph application and then attaching property maps to them. You may end up having to assign your own unique id's (which could actually be strings) , but at least you'll know how it's going to work.
Since the structure and the data types can change at run-time, I defined a map < string, any > as property, so the problem you described doesn't occur. Thanks for the warning, though. regards, Carlos Rafael Giani
participants (2)
-
Andrew Sutton -
Carlos Rafael Giani