Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-24 00:07:03

#5341: Patch to improve shared library behavior with serialization
----------------------------------------------+-----------------------------
  Reporter:  Aaron Barany <akb825@…>          |       Owner:  ramey                              
      Type:  Patches                          |      Status:  reopened                           
 Milestone:  To Be Determined                 |   Component:  serialization                      
   Version:  Boost 1.46.0                     |    Severity:  Problem                            
Resolution:                                   |    Keywords:  serialization shared_libraries dlls
----------------------------------------------+-----------------------------

Comment (by ramey):

 b) OK you guys have me here.

 a) you're beginning to convince me you know more about this than I do.  My
 concern was the case where serialization code for class A was instantiated
 in two different DLLS where there was no guarantee that they would be the
 same code.

 I have had problems with code which tracks pointers in one module and
 doesn't in some other module.  It looks like you've considered that.

 I'm still not seeing the import/export issue changes.

 Here are the things that I'm currently most concerned with:

 a) Implement concept checking for serialization and especially archive
 concepts.  Lack of this latter has lead to some ambiguities in how to use
 the existing code to make new archive classes.

 b) compile and test and include as examples submitted code for yaml and
 json archives

 c) create archives for gui editors - three flavors  MFC, QT and WX
 windows. These would work like this:

 given:
 class A {
    T1 m_a1;
    T2 m_a2;
    ...
    template<class Archive>
    void serialize(Archive &ar, unsigned int version){
      ar << NVP(m_a1);
      ...
    }
 };

 one could do the following
 create a dialog template. Controls would be named/tagged "m_a1", ...

 create dialogbox db;
 boost::archive::mfc_oarchive oa(db);
 // copy to dialog box
 oa << a;
 // user edits data
 boost::archive::mfc_oarchive ia(db);
 ia >> a; // get edited data.

 I once made such a thing but it was too much of a hack

 d) re-implement, document and test the concept of "archive helpers" which
 did dynamically what the current code does statically for shared_ptr. I
 realize now that I had it more right the first time.

 e) I don't want to keep cluttering up the archive concept with hacks like
 ar.reset_object_address.  So I want to create the concept of "archive
 manipulators" similar to the standard io manipulators.  In this way, not
 every archive would have to implement these extra functions.  Currently
 they don't only because they are implemented in the base class - but I
 want it to be easier to make archive classes which don't depend on the
 current implementation.  An example of an archive manipulator would be the
 pair, set_tracking(off)/restore_tracking.  This would permit the creation
 of an archive which would be better suited to sending transactions over
 the net.  Basically, it would keep the archive concept from continually
 growing.

 f) I want to trap NaN(s) in archives other than binary.  This could be
 overridden with a new flag on archive opening.

 I have a few more items on my list but I can't decipher them anymore.

 Robert Ramey

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5341#comment:10>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.