Boost logo

Boost Users :

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-02-01 16:59:26


Truth is I havn't gotten to it. Sorry. Its a very tricky area. One thing you might want to look at is the test which shows separate compilation. This avoids having the "same" code in both the executable and the dll which might help.

Robert Ramey

  "Marc Viala" <mviala_at_[hidden]> wrote in message news:92DC6B03E56CE74D9463089D3BF0A71068B911_at_serveur.acticm.com...
  Hi,

   

  I'm very sorry to post the message hereafter a second time, but I've not received any reply, maybe I've missed it.

   

  Any workaround or recommendations will be welcome because we are right now surrounded in our software development.

   

  Thanks in advance.

   

  Marc VIALA

   

   

   

  After few hour on the subject, I'm would like to have some explanations & recommendations one the boost serialization library. To explain, my problem, you will find hereafter a VC++ 7.1 project that demonstrates it.

   

  Problem Description

  We have involved in a large project with for example two DLLs libraries: LibA and LibB. These libraries define & implement one class, let's say libA::A and libB::B. These two classes can be serialized through boost serialization engine.

   

  The interfaces for the two classes are the same:

   

  ----------------------

  struct LIBA_API A

  {

    std::vector<double> my_vector ;

   

  private:

    friend class boost::serialization::access;

    template<class Archive>

      void save(Archive & ar, const unsigned int version) const ;

    template<class Archive>

      void load(Archive & ar, const unsigned int version) ;

   

    BOOST_SERIALIZATION_SPLIT_MEMBER()

  };

   

    LIBA_API

      void save(const libA::A* pObj, std::ostream& os) ;

    LIBA_API

      void load(libA::A* &pObj, std::istream& is) ;

  }; // Namespace libA

  ----------------------

   

  The two free functions save() and load() are defined to be able to serialize the class libA::A (respectively the class libB::B).

   

  When, we try to use these interfaces in an EXE application:

   

  ----------------------

  #include <LibA/A.h>

  #include <LibB/B.h>

   

  #include <boost/filesystem/path.hpp>

  #include <boost/filesystem/fstream.hpp>

   

  #pragma comment(lib, "liba_d.lib")

  #pragma comment(lib, "libb_d.lib")

   

  int

  main(int argc, char* argv[])

  {

    libA::A a;

    libA::save(&a, boost::filesystem::ofstream("a.xml"));

   

    libB::B b;

    libB::save(&b, boost::filesystem::ofstream("b.xml")); // -> Assert in debug mode

   

    return 0;

  }

  ----------------------

   

  The figure hereafter describes the relationships between LibA, LibB and EXE application:

                        ------------ ------------

                        | LibA | | LibB |

                        ------------ ------------

                                               \ /

                                                 \ /

                                                    Exe Application

   

  We have to face to an assert in debug mode generate by the file boost::serialization::extended_type_info.cpp, line#71. This assert happens during the instance serialization of class libB:B.

   

  Recently, there are some posts on this subject, but I would like to known how I can deal with this assert? Is it possible to avoid it by a code organisation? Is it possible to comment this assert?

   

  To have a concrete answer, I have joined my complete VC++7.1 project.

   

  Thanks in advance for your help.

   

  Development Platform

  WindowsXP

  VC++ 7.1

  Boost 1.33.1

   

  Marc Viala

  mailto:mviala_at_[hidden]

   

   

   

------------------------------------------------------------------------------

  _______________________________________________
  Boost-users mailing list
  Boost-users_at_[hidden]
  http://lists.boost.org/mailman/listinfo.cgi/boost-users



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net