From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2007-03-23 15:02:53
On 3/23/07, Robert Ramey <ramey_at_[hidden]> wrote:
> OK - I've taken a cursory look at this an it seems OK. I did have
> the expected "ripple" but it didn't end up so messy that I couldn't follow
> However, there has to be an easier way to test it. I needs to be
> in some way. We have a test "test_exported" - use that as a template.
> This will make the test compatible with our other tests and also
> permit it to be run against all future archives.
> I realize you might have to make two/three test programs - one/two
> to create the test archives and another to read them. Then we'll
> make sure they are run in sequence.
> Also we would need updated documentation for extended_type_info
> as well as BOOST_CLASS_EXPORT
> Robert Ramey
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I've attached a new patchfile and three new files that belong in the
serialization test directory. They currently fail, but so does the
test_exported.cpp test, which I did not change, except to fix a typo
in a comment. They fail in exactly the same way, with a thrown
boost::archive::archive_exception (what() == "unregistered void
cast"). I'm at a loss, so I'll leave finding this particular problem
to you, Robert.
I did not change the documentation (again, except for a couple of
typos). I'd be happy to do so later, but now seems to be the
appropriate time to reopen the issue of whether BOOST_CLASS_EXPORT()
should be given a warning in the docs or removed altogether. I favor
removing it altogether. Currently, it only acts as a slightly more
convenient form of BOOST_CLASS_EXPORT_GUID(), and as such users can
easily get along without it. With it, and even with a suitable
warning, over time users are bound to run into problems of classes
changing names, which will cause archive incompatabilities. The
ability to read and write archives compatably should trump the few
saved keystrokes that providing BOOST_CLASS_EXPORT() allows.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk