Requests for changes in 1.33 related to serialization
I want to suggest 2 changes that would be helpful at least to me, that relate to serialization. I use serialization with mersenne_twister and python. To support this 2 changes are needed: 1) serialization must be build as a shared library. I know this doesn't work on all platforms, but I believe it works on at least some, and therefore should be supported. 2) Please add support for serialization to mersenne_twister.hpp. All that's needed is this: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; }
Neal Becker wrote:
I want to suggest 2 changes that would be helpful at least to me, that relate to serialization.
I use serialization with mersenne_twister and python. To support this 2 changes are needed:
1) serialization must be build as a shared library. I know this doesn't work on all platforms, but I believe it works on at least some, and therefore should be supported.
Done in 1.33
2) Please add support for serialization to mersenne_twister.hpp. All that's needed is this:
template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; }
Hmm - well, if this doesn't make it into boost, I presume its not a obstacle for you. This raises a question that comes up from time to time. Where should code for serialization of other types be placed? An who should be responible for it? I would hope that individual library authors would take on the task of implementing serialization for the data types that they support. This has worked well with data-time, multi-index, and others. It hasn't worked for variant or shared_ptr. Next question is where should serializaton stuff be kept. Right now the ones I've done - e.g. shared_ptr are kept in boost/serialization/.... I believe others are kept in other places. I would like to see more consistency on this but really no consensus has been reached. It does seem that slow progress is being made here. So I would like to see you or someone else take this code, make tests for it and add it somewhere so it gets tested on all the compilers - which in the past has turned out to be a bigger task than one would expect (though I doubt that would be the case here). There are a few other data types that to me are natural candidates for serialziation, Quaternions, boost::any are ones I would like to see. Robert Ramey
On May 16, 2005, at 10:11 AM, Robert Ramey wrote:
This raises a question that comes up from time to time. Where should code for serialization of other types be placed? An who should be responible for it?
I presume that serialization code should always reside with the data type it serializes, unless it is impossible for some reason (e.g., cannot modify standard containers)? As for responsibility... whoever is interested will end up being responsible, since we're all volunteers anyway :)
I would hope that individual library authors would take on the task of implementing serialization for the data types that they support. This has worked well with data-time, multi-index, and others. It hasn't worked for variant or shared_ptr.
It'll happen, I'm sure. I know I'd like to do it for the graph library, but it's a rather large undertaking and I haven't had the time. I'm sure other library authors and maintainers are in the same situation. Doug
Robert Ramey wrote:
2) Please add support for serialization to mersenne_twister.hpp. All that's needed is this:
template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; }
If these are added, could they use BOOST_SERIALIZATION_NVP(x) and BOOST_SERIALIZATION_NVP(i) otherwise they won't work with XML archives. Cheers Russell
Robert Ramey wrote:
Neal Becker wrote:
I want to suggest 2 changes that would be helpful at least to me, that relate to serialization.
I use serialization with mersenne_twister and python. To support this 2 changes are needed:
1) serialization must be build as a shared library. I know this doesn't work on all platforms, but I believe it works on at least some, and therefore should be supported.
Done in 1.33
2) Please add support for serialization to mersenne_twister.hpp. All that's needed is this:
template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; }
Hmm - well, if this doesn't make it into boost, I presume its not a obstacle for you.
Not sure what you mean. It is an obstacle. I use boost::python to to wrap boost::random, and want serialization. I am giving my code to others, and now the only way to make it work is for them to patch mersenne_twister.hpp, (as well as building serialization as a shared lib).
Somewhere in the E.U., le 24/05/2005 Bonjour In article <d6ad62$782$1@sea.gmane.org>, "Robert Ramey" <ramey@rrsd.com> wrote: [SNIP]
There are a few other data types that to me are natural candidates for serialziation, Quaternions, boost::any are ones I would like to see.
Robert Ramey
After Boost 1.33 comes out, I'll try again to make serialization work in my setting (I am dropping CW and concentrating upon Gcc, under MacOS X). If it does, I'll immediately add support for quaternions and octonions. Merci Hubert Holin
On May 24, 2005, at 6:27 AM, Hubert Holin wrote:
There are a few other data types that to me are natural candidates for serialziation, Quaternions, boost::any are ones I would like to see.
Robert Ramey
After Boost 1.33 comes out, I'll try again to make serialization work in my setting (I am dropping CW and concentrating upon Gcc, under MacOS X).
There are some CodeWarrior failures with octonions and quaternions (with cw-9_4 for Windows). Have you had a chance to fix these yet? Doug
Somewhere in the E.U., le 26/05/2005 Bonjour In article <212cfa09f0f3d173fe23caaed435abd2@cs.indiana.edu>, Doug Gregor <dgregor@cs.indiana.edu> wrote: [SNIP]
There are some CodeWarrior failures with octonions and quaternions (with cw-9_4 for Windows). Have you had a chance to fix these yet?
Doug
Both cw-9_4 for Windows and Intel 8.1 define symbols which trip a supplied workaround for MSVC deficiencies about "abs" & co.: #if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || (defined(_MSC_EXTENSIONS) && BOOST_MSVC < 1310)) Both, however, seem to work around the deficiency, but in different ways. I do not have access to any of these platforms, so there is not much I can do. I will try to see if more specific symbols are defined for these platforms and exclude them from the workaround in place, but any suggestion is welcome. The gcc 4.0 & Sun situation is more problematic: the standard library that ships with them is broken with respect to "long double" (in these cases, "float", "double" and "long double" really are three distinct things, and some special functions have not been coded correctly for the highest precision one). I can either disable "long double" support for them, relax conditions to a point where "long double" is no better than "double" or mark these as expected failures. I am equally unhappy with each of these. What would a preferred solution be? Merci Hubert Holin
Hubert Holin wrote:
Both cw-9_4 for Windows and Intel 8.1 define symbols which trip a supplied workaround for MSVC deficiencies about "abs" & co.:
#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || (defined(_MSC_EXTENSIONS) && BOOST_MSVC < 1310))
Both, however, seem to work around the deficiency, but in different ways. I do not have access to any of these platforms, so there is not much I can do. I will try to see if more specific symbols are defined for these platforms and exclude them from the workaround in place, but any suggestion is welcome.
For CW.. You can look in boost/config/compiler/metrowerks.hpp to see all the versions that are defined. For the 9.x series you could: #if BOOST_WORKAROUND(__MWERKS__, >= 0x3201) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Somewhere in the E.U., le 27/05/2005 Bonjour In article <4295DB2F.2040100@redshift-software.com>, Rene Rivera <grafik.list@redshift-software.com> wrote:
Hubert Holin wrote:
Both cw-9_4 for Windows and Intel 8.1 define symbols which trip a supplied workaround for MSVC deficiencies about "abs" & co.:
#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || (defined(_MSC_EXTENSIONS) && BOOST_MSVC < 1310))
Both, however, seem to work around the deficiency, but in different ways. I do not have access to any of these platforms, so there is not much I can do. I will try to see if more specific symbols are defined for these platforms and exclude them from the workaround in place, but any suggestion is welcome.
For CW.. You can look in boost/config/compiler/metrowerks.hpp to see all the versions that are defined. For the 9.x series you could:
#if BOOST_WORKAROUND(__MWERKS__, >= 0x3201)
I commited a possible fix for the quaternion test. If it works (and if it does not break the fix Beman contributed for the Intel compiler - Thanks Beman!) I'll propagate it to the octonions as well. Merci Hubert
participants (2)
-
Doug Gregor -
Hubert Holin -
Neal Becker -
Rene Rivera -
Robert Ramey -
Russell Hind