
On Sun, 23 Mar 2008 14:33:40 +0000, Jerry wrote:
Robert,
Note that results should be the same with all types of archives. This is a fundamental goal of the library. So if you can make an example which > fails with binary archive but passes with another one - that would be of interest.
It is a header ordering issue.
Yep, this is outline in the doc that I linked you to earlier. [snip]
I now realise that
now needs to follow any of the archive headers. The #include order determines which failure will occur - something that might be added to the comments in the code. Is there any way to detect this problem at compile /link time?
One thing I really like about the serialization library is that there are lots of asserts with lots of comments telling you what went wrong and how to fix it. Perhaps a gentle reminder about the header-order issue would have been appropriate. The development version of Boost is supposed to have removed the need for header ordering but I think the kinks are still being worked out: http://article.gmane.org/gmane.comp.lib.boost.devel/172425 -- Sohail Somani http://uint32t.blogspot.com