Re: Boost serialization of intrusive_ptr?

Discussion in 'C++' started by Bart van Ingen Schenau, Sep 2, 2009.

  1. On Sep 2, 3:42 am, Bradley Wilson <> wrote:
    > Yannick Tremblay wrote:
    > > So it sounds to me that you need to save the content of your memory
    > > pools to disk and boost::serialiser is a useful framework to serialise
    > > the data, then you need to read the data from disk and load it into
    > > your memory pools.  The data saved on disk doesn't need to know about
    > > memory pools, only the load data method needs to know where to place
    > > the data it reads from disk.

    >
    > I am using the boost::serialize framework. However, it A) Doesn't by
    > default support intrinsic pointers (although I'm staring to see that
    > adding serialization support should be fairly easy), and:
    >
    > B) The real trouble is that the data pointed to by the intrinsic pointers
    > is allocated from a memory pool, and memory pools don't appear to be
    > serializable.


    But why would you want to serialisa a complete memory pool?
    Would it not be sufficient if, on serialisation, the individual
    objects are serialised and on deserialisation it is ensured the new
    objects are created within a suitable memory pool?

    >
    > Here's the issue:
    >

    <snip>
    > This is all fine and dandy, but it won't work for deserializtion.
    > There's no way
    > to tell it that a particular incoming pointer actually points to the
    > middle of an
    > allocated block of memory that was previously loaded.
    >
    > This also means you can't serialize pointers that point into an array:
    >
    >         my_object *a = new my_object[10];       // Array
    >         my_object *b = a + 5;                           // Pointer to middle of array
    >
    >         // Open archive for saving
    >         ...
    >         archive << a;     // Assume we store a+5 in the swizzle map directly in
    >                                         // my_object's serialize routine
    >
    >         archive << b;     // Data is not written, due to previous swizzle trickery
    >
    >         // Open archive for loading
    >         my_object *c, *d;
    >
    >         archive >> c;     // Should work correctly, entire array is loaded
    >
    >         archive >> d;     // Will not work as advertised - new memory is
    >                                         // allocated because archive doesn't know that d
    >                                         // points into the interior of c.


    Have you actually verified that this does not work in the way
    described here?
    Because I would expect that the swizzle trickery (if implemented
    correctly) writes out a marker to indicate: on deserialisation, ensure
    this pointer refers to the object that was reconstructed from the data
    'over there'.

    >
    > So unless some wizard out there has already figured out a way around
    > this problem,
    > I'm going to have to alter my approach to how to save state. (I have an
    > idea, but
    > it's madness.)


    I would say that trying to serialise a memory pool is a sure way to
    madness. And it is not needed.
    The exact way in which the various objects are allocated within the
    memory pools should not be part of the state of your game. The fact
    that objects A and B are located in pool P and object C is in pool Q
    is information that should be known statically at the places where the
    objects are created, and if you change your mind and move B to pool Q
    as well, then reloading an old state (from before the change) should
    reflect the new reality.

    Bart v Ingen Schenau
    Bart van Ingen Schenau, Sep 2, 2009
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    8
    Views:
    2,242
    deadsea
    Jan 2, 2005
  2. Steven T. Hatton

    #include <boost/intrusive_ptr.hpp>

    Steven T. Hatton, Jun 15, 2005, in forum: C++
    Replies:
    4
    Views:
    2,624
    Steven T. Hatton
    Jun 15, 2005
  3. Replies:
    3
    Views:
    1,026
  4. Pallav singh

    shared_ptr<T> vs intrusive_ptr<T>

    Pallav singh, Apr 28, 2009, in forum: C++
    Replies:
    1
    Views:
    1,413
    Noah Roberts
    Apr 28, 2009
  5. Francesco
    Replies:
    1
    Views:
    850
    Francesco
    Sep 2, 2009
Loading...

Share This Page