| 
 | SerializationException Safety | 
The process of loading an archive may result in the creation of new objects.  That
same process may throw an exception at some point. In order to prevent memory leaks
and invalid pointers, these situations must be considered.  Unfortunately, there is
no simple universal solution to this problem.  The manner of addressing this must
depend on the design of the data structures to be serialized.  Below, we discuss
varying scenarios in increasing order of difficulty.  This discussion presumes that
the class member functions are exception safe before considering serialization.  
That is, the destructor could be called at anytime without referencing 
an invalid pointer, or creating a memory leak.
    - class contains no pointersNo problem here.- 
     
- class contains only owned pointersFrom here on, we have to make a distinction between pointers used
    to manage heap storage (owned pointers) and pointers used to refer
    to related objects (referenced pointers).  Programs containing owned
    pointers must contain code for deleting these objects and returning the
    deallocated storage to the heap.  Programs containing referenced pointers
    must be designed to ensure that no such referenced pointers are de-referenced
    after the object pointed to has been destroyed and its storage returned
    to the heap. If a pointer is stored in only one place, it must be an owned
    pointer.- 
    The load function traps any exceptions that occur between the time an object
    is created and its pointer is stored.  Should an exception occur while
    reading an archive, the created object is deleted and the de-serialized
    pointer is set to NULL.  This ensures that there are no memory leaks.
    The fact that there are no other copies of this pointer ensures that
    no pointers are left invalid. The object's destructor should
    be able to delete any other existing objects in the normal manner
    without problem.
    test_delete_pointer.cpp
    illustrates this case.
     - 
     
- class contains one or more referenced pointersThis situation can be further subdivided into two cases- 
     - 
        - owned pointers are always serialized before referenced pointersObject tracking will ensure that no new objects will be created
        by the loading of a referenced pointer.
        If an exception occurs, referenced pointers will not need to be deleted
        so there will be no memory leaks. The destructor of this class won't attempt to
        delete these pointers so there will be no problem with dangling references.
        Owned pointers are handled exactly as described above.- 
         
- class contains referenced pointers which might be created by loadIf a referenced pointer is loaded before its corresponding owned
        pointer, the object will be allocated on the heap.  In certain cases
        it cannot be known which pointers were created by their owners and which
        were created by the load function.  To address this:- 
        - Trap exceptions with a try/catchblock.
- Within the catch part, invoke the archive function 
        delete_created_pointers()to delete any pointers
        created by the class load.  Without other action, objects created in
        this way would end up as memory leaks as they are not considered owned
        pointers and hence aren't destroyed.
- The object's destructor won't try
        to delete referenced pointers so any dangling references will
        cause no harm.
    
 demo_exception.cpp
        is a program that illustrates this case.- 
     
 - 
     
- Other casesSituations not covered above are pointers for which the classifications of 
    referenced and owned are not applicable.  This might occur where
    pointers are created by one class but consumed and deleted by another.  These
    may be addressed with an ad hoc analysis similar to the above.  As the
    situation becomes more complex this becomes more difficult and error prone.
    Eventually, it will be have to addressed by building heap management into the
    pointer itself - that is into- boost::shared_ptr. 
    The library includes serialization of- boost::shared_ptr.  As
    previously mentioned, this required a tiny alteration in one of the- boost::shared_ptrimplementation files in order to permit
    access by the serialization system.
© Copyright Robert Ramey 2002-2004. 
Distributed under the Boost Software License, Version 1.0. (See
accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)