From what I can see, I do not have to care about the reference counter inside of the smart pointer. An object that is serialized and de-serialized somewhere else has a life on its own there. In my case,

Dear Robert, thanks a lot! Do I understand it correctly, that I could easily create my own serializer for std::shared_ptr by just (de)serializing the contained "raw" pointer and wrapping it into a std::shared_ptr in the case of de-serialization ? the objects are sent back later, but from the time of arrival back in the home system lead a life of their own. Best Regards, Ruediger Am 30.04.15 um 23:16 schrieb Robert Ramey:

Rüdiger Berlich wrote

...

Hi there,

I need to support various versions of Boost, but am in the process of porting our entire code base to C++11. This involves replacing those constructs of Boost that are now in the standard with their C++11-counterparts.

A prime example is std::shared_ptr. However, most of our code needs to be serializable. I know that serialization of std::shared_ptr is possible with Boost 1.58. But 1.53 (the oldest version I need to support) cannot serialize std::shared_ptr .

Is there any reason not to include the 1.58-Version of

#include <boost/serialization/shared_ptr.hpp>

instead of the older version, if I detect a Boost-version < 1.58 ?

I believe that #include <boost/serialization/shared_ptr.hpp> should support both boost::shared_ptr as well as std::shared_ptr. Check test_shared_ptr. I believe this is illustrated here.

Note that this is an unusual case since boost shared_ptr serialization is supported in the serialization library rather than the boost smart_ptr library so the above advice is not universally applicable.

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/serialization-std-shared-ptr-with-Boost-1... Sent from the Boost - Users mailing list archive at Nabble.com. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Dear Robert, see below for a simple test program that illustrates what I'm trying to do. This compiles with Boost 1.58, but fails on 1.53 with the error message /opt/boost153/include/boost/serialization/access.hpp:118:11: error: no member named 'serialize' in 'std::__1::shared_ptr<test>' t.serialize(ar, file_version); I need to support Boost versions starting with 1.53. Thus I have two options: - do serialization of std::shared_ptr myself - include the 1.58 boost/serialization/shared_ptr.hpp for older Boost-versions. What is the best way ? Thanks and Best Regards, Beet /*******************************************************/ // Compile with // g++ --std=c++11 -o sharedptr sharedptr.cpp -I /opt/boost158/include/ // -L/opt/boost158/lib -lboost_serialization -lboost_system // on MacOS, Linux #include <iostream> #include <memory> #include <sstream> #include #include #include #include #include class test { /////////////////////////////////////////////////////////////////////// friend class boost::serialization::access; template<typename Archive> void serialize(Archive & ar, const unsigned int) { using boost::serialization::make_nvp; ar & BOOST_SERIALIZATION_NVP(secret_); } /////////////////////////////////////////////////////////////////////// public: test(): secret_(1) {} private: int secret_; }; int main() { std::vector t_vec, t_vec2; std::ostringstream oss; t_vec.push_back(std::shared_ptr<test>(new test())); // save data to archive { boost::archive::xml_oarchive oa(oss); // write class instance to archive oa & BOOST_SERIALIZATION_NVP(t_vec); // archive and stream closed when destructors are called // Data is now in oss } // load data from archive { std::istringstream iss(oss.str()); boost::archive::xml_iarchive ia(iss); // read class state from archive ia & BOOST_SERIALIZATION_NVP(t_vec2); // archive and stream closed when destructors are called } return 0; } /*******************************************************/ Am 04.05.15 um 01:34 schrieb Robert Ramey:

beet-2 wrote

...

Dear Robert,

thanks a lot! Do I understand it correctly, that I could easily create my own serializer for std::shared_ptr by just (de)serializing the contained "raw" pointer and wrapping it into a std::shared_ptr in the case of de-serialization ?

No. You have to keep track of other shared pointers point

I had assumed from the question that the situation was something like:

// version 1 myclass { boost::shared_ptr m_p ... } // version 2 myclass { std::shared_ptr m_p ... };

and the question was asking how the latest version code would de-serialize older version (version 1) archives (data files)

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/serialization-std-shared-ptr-with-Boost-1... Sent from the Boost - Users mailing list archive at Nabble.com.

Robert, there seems to be a misunderstanding here, and I apoligize for not having been more clear before. Here is the history again: - I have converted a client-server application from using boost::shared_ptr to std::shared_ptr - The server now needs to serialize a ** std::shared_ptr ** and the client wants to receive a ** std::shared_ptr ** - No boost::shared_ptr is involved anymore, and the problem is NOT the conversion from a boost::shared_ptr - based archive to a std::shared_ptr archive - Serialization of std::shared_ptr works with Boost 1.58, but isn't supported by Boost 1.53 - I need to make it work with older versions of Boost than 1.58, so I need to "teach" 1.53 to (de-)serialize a std::shared_ptr There seem to be two options here: - Back-porting the 1.58 boost/serialization/shared_ptr.hpp and conditionally including it, when I detect Boost versions older than 1.58 - Creating my own (de-)serialization code for a std::shared_ptr My question really was, whether backporting 1.58's boost/serialization/shared_ptr.hpp to Boost 1.53 is feasible . Best Regards, Beet Am 04.05.15 um 18:04 schrieb Robert Ramey:

The serialization library includes code to serialize both boost::shared_ptr and std::shared_ptr.

The serialization library also includes effective facilities for handling multiple versions of class en the evolution of versioning over time. This is explained in the manual and illustrated via numerous examples.

The only thing I can say is that you should spend a little more time studying the documentation and making some test programs to become familiar with it.

Robert Ramey

-- View this message in context: http://boost.2283326.n4.nabble.com/serialization-std-shared-ptr-with-Boost-1... Sent from the Boost - Users mailing list archive at Nabble.com.

Hi Michael,

If it's me making that decision, I opt for progression, not regression, making it work for 1.58+. There may be good reasons for considering 1.53 still, breaking changes, etc, however.

I would personally certainly prefer using solely the newest versions of Boost. However, installation of our library (the Geneva library of distributed optimization algorithms -- see http://launchpad.net/geneva) already requires a fair deal of hand-work (i.e. compilation of the Geneva code, usually). I do not want force users to have to compile different Boost versions for different versions of Geneva. And Boost 1.53 is still the default version in some common Linux distributions with a large installed base. So if I have the choice of a) forcing the user to always install the newest Boost version or b) having to go through some pains myself to make older Boost versions work with our code, I opt for simplicity on the side of the user. Best Regards, Ruediger

Am 04.05.15 um 20:04 schrieb Michael Powell:

...

So if I have the choice of a) forcing the user to always install the newest Boost version or b) having to go through some pains myself to make older Boost versions work with our code, I opt for simplicity on the side of the user.

Notwithstanding logistical concerns...

By which you refer to #ifdef-orgies ? These can be bad (as I had to learn when we ported the code to MSVC), agreed. Supporting multiple Boost-versions was usually rather painless so far, though, with only a few minor problems. And our current "std::shared_ptr"-problems are triggered solely by my decision to be progressive and to support C++11 only in the future (as of the current trunk version of Geneva) :-) . And I rather feel that, if I do this, I don't want to go half way. So I have replaced all boost::shared_ptr with std::shared_ptr in Geneva (1.7x). boost.bind has gone away (mostly replaced by C++11-lambdas) and I'm working on std::thread (for which I need to implement the interrupt() functionality of boost::thread . Best Regards, Ruediger

beet-2 wrote

Robert,

there seems to be a misunderstanding here, and I apoligize for not having been more clear before. Here is the history again:

- I have converted a client-server application from using boost::shared_ptr to std::shared_ptr

- The server now needs to serialize a ** std::shared_ptr ** and the client wants to receive a ** std::shared_ptr **

- No boost::shared_ptr is involved anymore, and the problem is NOT the conversion from a boost::shared_ptr - based archive to a std::shared_ptr archive

- Serialization of std::shared_ptr works with Boost 1.58, but isn't supported by Boost 1.53

- I need to make it work with older versions of Boost than 1.58, so I need to "teach" 1.53 to (de-)serialize a std::shared_ptr

I can't see why you can't just handle use versioning of serializable classes as described in the manual. struct myclass { std::shared_ptr<Sometype> m_x; // used to use boost::shared_ptr<Sometype> ... template<class Archive> serialize(Archive & ar, const unsigned int version){ if(version < 1){ boost::shared_ptr t; ar & t; m_x = t; } else { ar & m_x; }; }; BOOST_SERIALIZATION_CLASS_VERSION(myclass, 1); OK - I see the problem, matching up the matching pointers. Look at how boost::shared_ptr and std::shared_ptr are implemented via serialization helper and look at the decimation on serialization helper. This might work for you Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-std-shared-ptr-with-Boost-1... Sent from the Boost - Users mailing list archive at Nabble.com.