Note:
Boost’s archive scheme is based on symmetrical input and output archive classes. It’s tedious to write about both of them all the time, so I’ll use ?archive to mean both oarchive and iarchive.
Summary:
After changing the base classes of my custom archives from binary_?archive_impl to text_?archive_impl, my custom archive classes are no longer “found” when the compiler is instantiating the serialize(...) methods in my other classes.
Background:
My application was successfully reading and writing files to disk using subclasses of binary_?archive_impl (the documentation and/or code comments recommend this over deriving from binary_?archive). I needed to switch from a binary file format to a text format, so I switched the base classes of my custom archives to text_?archive_impl. That’s when everything blew up.
The problem:
My custom archive classes add functionality, including some additional methods which do not exist in their Boost base classes; these methods are called in the serialize(...) methods in many of my classes, and they were working fine. After changing the base classes from binary_?archive_impl to text_?archive_impl, I received compilation errors all over the place complaining that my custom methods do not exist in text_?archive. Well, that’s obvious (!!!), but they do exist in my custom archives, and they were working just fine when I was using Boost’s binary base classes. What’s the deal?
What I found, and my temporary – but undesirable – solution:
After tearing my hair out and going around in circles for about a day, this is what I found…
1) Some time ago (Boost 1.34 I believe), the files “binary_?archive.hpp” were split up into “binary_?archive_impl.hpp” and “binary_?archive.hpp” (the latter #include the former). This was not done to “text_?archive.hpp”. (As a result, I changed my application’s #include lines from “binary_?archive_impl.hpp” to simply “text_?archive.hpp”.)
2) If I split up “text_?archive.hpp” into two parts and #include only the “…_impl.hpp” headers, everything works. (But I really don’t want to modify my Boost installation!)
3) Looking more closely at these headers and fiddling around a bit, I found that if I use the original, unmodified headers and comment out the line
BOOST_SERIALIZATION_REGISTER_ARCHIVE(boost::archive::text_oarchive)
(and likewise for text_iarchive), then everything works fine again. (By the way I have similar lines in my own archive code to “register” my custom archives.)
The mystery, and my dilemma:
A) Why does the presence of those lines foul up the works? …and why does removing them make things work? …and what might I have broken (without knowing it) by doing so?
B) Why were the “text_?archive.hpp” files not split up along with the “binary_?archive.hpp” files a long time ago? (Is the library broken? Should it be fixed?)
C) Is there any way to solve this in my application code without modifying my Boost installation?
P.S. I’m using Boost 1.48 and Visual Studio 2010 (64-bit)
P.P.S. I imagine all of the above would apply equally to text_w?archive
As best I can tell its a bug in boost serialize. We’ll see here.
A)
1. Adding BOOST_SERIALIZATION_REGISTER_ARCHIVE with you new archive does not work because the default text archives have already been registered – only on registration seems to be allowed.
2. Removing them makes it work because only your custom classes are registered.
3. By removing them you’ve broken the ability to use the default text archive – your classes will be registered.
B)
I’m fairly certain that the “text_?archive.hpp” files should have been split up like the “binary_?archive.hpp” files are. Patch boost anyone?
C)
The best solution is to submit a patch to boost that splits the files up. For a temporary solution probably the best way is to put the patched files locally in your project until the patch makes it into boost.