Problem with serialization mersenne_twister with cvs
This used to work with 1.32.0, but is failing with cvs. In mersenne_twister.hpp, I add template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; } Now compile: g++4 -g -DNDEBUG -O3 -ftree-vectorize -msse2 -ffast-math -fstrict-aliasing -Wall -fPIC -I/usr/local/src/boost.cvs -I/usr/include/python2.4 -I/home/\ nbecker/shannon2.darcs/src -c -o boost_rand.os boost_rand.cc /usr/local/src/boost.cvs/boost/archive/detail/oserializer.hpp: In function 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive:\ :binary_oarchive, T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u\
]': /usr/local/src/boost.cvs/boost/archive/basic_binary_oarchive.hpp:69: instantiated from 'void boost::archive::basic_binary_oarchive<Archive>::save\ _override(T&, int) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346\ 425566u>, Archive = boost::archive::binary_oarchive]' /usr/local/src/boost.cvs/boost/archive/binary_oarchive.hpp:47: instantiated from 'void boost::archive::binary_oarchive_impl<Archive>::save_overri\ de(T&, int) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u\ , Archive = boost::archive::binary_oarchive]' /usr/local/src/boost.cvs/boost/archive/detail/interface_oarchive.hpp:89: instantiated from 'Archive& boost::archive::detail::interface_oarchive<A\ rchive>::operator<<(T&) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18,\ 3346425566u>, Archive = boost::archive::binary_oarchive]' boost_rand.cc:41: instantiated from here /usr/local/src/boost.cvs/boost/archive/detail/oserializer.hpp:557: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTI\ ON_FAILURE<false>'
This is not a problem with your serialization function. But somewhere else. Note the section in the manual under "tracking" addresses this. This describes requirements re const-ness that were documented but only recently enforced. Robert Ramey Neal Becker wrote:
This used to work with 1.32.0, but is failing with cvs.
In mersenne_twister.hpp, I add template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; }
Now compile: g++4 -g -DNDEBUG -O3 -ftree-vectorize -msse2 -ffast-math -fstrict-aliasing -Wall -fPIC -I/usr/local/src/boost.cvs -I/usr/include/python2.4 -I/home/\ nbecker/shannon2.darcs/src -c -o boost_rand.os boost_rand.cc /usr/local/src/boost.cvs/boost/archive/detail/oserializer.hpp: In function 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive:\
binary_oarchive, T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u\ ]': /usr/local/src/boost.cvs/boost/archive/basic_binary_oarchive.hpp:69: instantiated from 'void boost::archive::basic_binary_oarchive<Archive>::save\ _override(T&, int) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346\ 425566u>, Archive = boost::archive::binary_oarchive]' /usr/local/src/boost.cvs/boost/archive/binary_oarchive.hpp:47: instantiated from 'void boost::archive::binary_oarchive_impl<Archive>::save_overri\ de(T&, int) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u\ , Archive = boost::archive::binary_oarchive]' /usr/local/src/boost.cvs/boost/archive/detail/interface_oarchive.hpp:89: instantiated from 'Archive& boost::archive::detail::interface_oarchive<A\ rchive>::operator<<(T&) [with T = boost::random::mersenne_twister<uint32_t, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18,\ 3346425566u>, Archive = boost::archive::binary_oarchive]' boost_rand.cc:41: instantiated from here /usr/local/src/boost.cvs/boost/archive/detail/oserializer.hpp:557: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTI\ ON_FAILURE<false>'
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, 27 May 2005 20:48:51 -0700, Robert Ramey wrote
This is not a problem with your serialization function. But somewhere else. Note the section in the manual under "tracking" addresses this. This describes requirements re const-ness that were documented but only recently enforced.
Yet more fallout from the 'const-enforcement' change and it hasn't even been released. I predict an explosion of user problems after the release of 1.33 as working code fails to compile and users are force to artificially make things 'const'. I'll shutup after this email, but in case it wasn't obvious I think this serialization change is very misguided... Jeff
Please don't get the impression I'm not sympathetic to you're (and others concerns about this). I am. We'll hear on the list complaints about this from time to time. On the other hand, we won't hear complaints from those who encountered the STATIC_ASSERT, puzzled a bit, maybe read the manual and tweaked the code so the STATIC_ASSERT goes away, and serialization works just as we expect it to. If we don't trap this situation, serialization tracking will not work and the error will not be immediatly apparent and users may have to spend a very, very, long time to track it down. We may not even hear from these people as they might just conclude its not worth the effort. So, I'm not confident that the number of "broken cases" complained about on the list is an accurate indicator of what the correct thing to do is. I don't see this change as "breaking code" but rather detecting code that is very likely already broken. So, as I said, its not that I'm unsympathetic to your point of view, I just don't think everyone is sympathetic to mine. Robert Ramey Jeff Garland wrote:
On Fri, 27 May 2005 20:48:51 -0700, Robert Ramey wrote
This is not a problem with your serialization function. But somewhere else. Note the section in the manual under "tracking" addresses this. This describes requirements re const-ness that were documented but only recently enforced.
Yet more fallout from the 'const-enforcement' change and it hasn't even been released. I predict an explosion of user problems after the release of 1.33 as working code fails to compile and users are force to artificially make things 'const'. I'll shutup after this email, but in case it wasn't obvious I think this serialization change is very misguided...
Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote
Please don't get the impression I'm not sympathetic to you're (and others concerns about this). I am. We'll hear on the list complaints about this from time to time. On the other hand, we won't hear complaints from those who encountered the STATIC_ASSERT, puzzled a bit, maybe read the manual and tweaked the code so the STATIC_ASSERT goes away, and serialization works just as we expect it to.
If we don't trap this situation, serialization tracking will not work and the error will not be immediatly apparent and users may have to spend a very, very, long time to track it down. We may not even hear from these people as they might just conclude its not worth the effort. So, I'm not confident that the number of "broken cases" complained about on the list is an accurate indicator of what the correct thing to do is.
I don't see this change as "breaking code" but rather detecting code that is very likely already broken.
So, as I said, its not that I'm unsympathetic to your point of view, I just don't think everyone is sympathetic to mine.
Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I don't think that Vladimir, myself, or the others that have posted on this topic are convinced that this change is really going to prevent people from making the error you are concerned about. OTOH, we can all see that much perfectly working user code will now not compile and that in common use cases people will start 'hacking' their code with casts or other work arounds b/c they want to serialize non-const data. And while the interface might have been documented during the review it's clear none of us understood the implications -- we wrote code and when it worked we presumed that since it worked we understood the interface... Jeff
Jeff Garland wrote:
On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote
[...]
I don't see this change as "breaking code" but rather detecting code that is very likely already broken.
So, as I said, its not that I'm unsympathetic to your point of view, I just don't think everyone is sympathetic to mine.
Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I don't think that Vladimir, myself, or the others that have posted on this topic are convinced that this change is really going to prevent people from making the error you are concerned about. OTOH, we can all see that much perfectly working user code will now not compile and that in common use cases people will start 'hacking' their code with casts or other work arounds b/c they want to serialize non-const data. And while the interface might have been documented during the review it's clear none of us understood the implications -- we wrote code and when it worked we presumed that since it worked we understood the interface...
The "const enforcement" is consistent with the spirit of the serialization library, which is identity-based. My own opinion is that a serialization library should be value-based, but that's a different story. I'm just pointing out where the const rule comes from.
Robert Ramey wrote:
This is not a problem with your serialization function. But somewhere else. Note the section in the manual under "tracking" addresses this. This describes requirements re const-ness that were documented but only recently enforced.
Robert Ramey
Please make sure the tutorials are updated to reflect this new constness.
participants (4)
-
Jeff Garland -
Neal Becker -
Peter Dimov -
Robert Ramey