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

Subject: Re: [Boost-users] boost serialize - stack overflow for large problems
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-01 14:26:18

On 09/29/2010 11:12 AM, Dominique Devienne wrote:
>
> 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.

3) Serialize the nodes through a sequence adapter which presents each 
node once. You may have that already.

Adapt the serialization of the nodes' vertex vectors to cast the node 
pointers to uint64_t or uintptr_ts (yes, I know). Systematically refer 
to that value as a "node ID" from now on.

On deserialization, maintain an associative container like:
        map<node_id_t, pair<node *, node**>>
such that the key is the node ID,
pr.first is either null or the deserialized object, and
pr.second is either null or points to the head of a singly-linked list 
formed of elements in the referencing nodes' vertex vectors.

After all nodes have been deserialized in this form, traverse each 
node's SLL and fixup the next node** with the new node *.

This assumes sizeof(node**) <= sizeof(node*) <= sizeof(node_id_t).
In my book there is, occasionally, a time and a place for 
reinterpret_cast. Maybe you could do it better with a union type, but is 
this odd case worth the additional type complexity? (Hmm, this is a 
Boost list we're on).

I've known this to be used successfully in practice (I think it was 
assembler though). The real danger with this scheme is that you'll never 
convince some coworkers that serializing the pointer isn't a bug.

Now that I think about it, in some cases it might be considered a 
security problem to leak information about heap layout though the 
pointer values. If this is the case, encrypt them all and throw away the 
key!

- Marsh