Carlos Rafael Giani | 11 May 14:43

[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?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Andrew Sutton | 12 May 15:28

Re: [graph] [serialization] serialized descriptors

> 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  
(Continue reading)

Carlos Rafael Giani | 12 May 17:17

Re: [graph] [serialization] serialized descriptors

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.

(Continue reading)


Gmane