Re: [Boost-users] boost serialize - stack overflow for largeproblems
Consider a triangulated surface, made up of nodes. Each node has an ordered list of its neighbors (nodes) that implicitly defines all the triangles having the node as an apex.
The surface "owns" the nodes (in a vector let's say). The neighboring nodes of a node are not owned OTOH, yet the connectivity info (the topology) they represent must still be persisted for each node. And that info happens to be a vector of pointers of other nodes of the same surface.
When you serialize the surface, you must serialize all its nodes, and all those nodes' topology too. If you do it depth first, you end up blowing up the stack indeed.
I see two possible solutions:
1) save all the nodes *without* their topology info on a first pass of the vector, thus recording all the "tracked" pointers for them, then write the topology info for each, since then you don't "recurse", you only write a "ref" to an already serialized pointer. That's my suggestion.
This has the problem that I totally change the existing serialization routines. Since I have to go twice through my structure (in the first pass serializing the nodes and in the second pass their topology information) I would need two serialize routines. Since the library supports only a single method for each class (the serialize method), I'd have to implement at least parts of the serialization library myself.
2) have the possibility to write a "weak reference" to a pointer, which only adds the pointer to the "tracking" map with a special flag saying it wasn't "really" written yet, such that writing the topology of a node that wasn't yet written is akin to "forward references" to those neighboring nodes. Either the node will really be written later on, or it never will, and I suppose serialization should handle that gracefully. I'd have to think about this.
This idea seems to be very appealing and if there is a possibility to implement that into the serialization library that would be great.
"Jörg F. Unger" wrote:
2) have the possibility to write a "weak reference" to a pointer, which only adds the pointer to the "tracking" map with a special flag saying it wasn't "really" written yet, such that writing the topology of a node that wasn't yet written is akin to "forward references" to those neighboring nodes. Either the node will really be written later on, or it never will, and I suppose serialization should handle that gracefully. I'd have to think about this.
This idea seems to be very appealing
except that it would have the same stack depth as the current solution. and if there is a possibility to
implement that into the serialization library that would be great.
Not going to happen. One final thing would work for you. If you separated your node data from the graph data and serialized the node data first you would have no problem. It could well be that mixing the node data and grapharcs inside the same structure might not be a great idea in any case. Robert Ramey
participants (2)
-
"Jörg F. Unger"
-
Robert Ramey