Re: [Boost-users] boost serialize - stack overflow for largeproblems

Subject: Re: [Boost-users] boost serialize - stack overflow for largeproblems
From: Jörg F. Unger (j-unger_at_[hidden])
Date: 2010-09-29 15:24:33

>>  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.