Seialization library current status

Here is short summary of the current status of the serialization library. Its based on tests on my own machine and others. In some cases I'm anticipating results of next tests. Linux - 100 % passing all compilers Except intel 8.0 - problem with serialization some collections - list, map, set, and array. Darwin - 100 * passsing Except - one test of demo fail Windows Mingw - 100 % of all char archives 0 % of wchar_t archives. Apparently mingw doesn't support wchar_t. Itel 100 % all versions Borland - mostly passing - this is the best I can do here VC <= 7.0 - mostly passing - this is the best I can do here VC 7.1 - 100% VC 8.0 - 0% - I don't know the status of this compiler. Library fails to build due to syntax error compiling spirit headers. I'm not prepared to address this. Commeau - 100 % EXCEPT archives which use wide characters. I believe it would be easy to find if I could figure out a way to debug this. Metrowerks CodeWarrior - This is a little confusing. One tester shows 100% success. The best I have is all pass EXCEPT tests which use export facility or wchar_t archives. Another tester has the same result I do. All tests that fail have unexpected linker warnings. I suspect a build issue but have been unable to find it. So that's it I could use help with Intel 8.0 array, list, set and map. Its probably one error in collection loading. Comeau - problems with wchar_t. Very likely related to codecvt facit usage Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which use utf8_codecvt_facet and which use export. Export seems to fail due to an over zealous link time optimizer eliminating what might look like dead code. Robert Ramey

"Robert Ramey" <ramey@rrsd.com> writes:
Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which use utf8_codecvt_facet and which use export. Export seems to fail due to an over zealous link time optimizer eliminating what might look like dead code.
?? CW doesn't support export ?? Are you aware that some of the facet stuff is only supported in the *statically-linked* version of the MW standard library? <runtime-link>static might be a requirement of these tests. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Robert Ramey wrote:
Comeau - problems with wchar_t. Very likely related to codecvt facit usage
if we (you with my help) could come up with some simple code to reproduce the problem, I could report it then to Comeau - support is very helpful, and if the problem is with libcomo, fix could be ready in one day. So far I'm unable to debug Boost test unit produced by como on MSVC71 backend :( - but anyway I will try this first. Maybe you could prepare some tests of codecvt, similar to the way it's utilized by serialization library? B.

Bronek Kozicki wrote:
So far I'm unable to debug Boost test unit produced by como on MSVC71 backend :( - but anyway I will try this first. Maybe you could prepare
OK, I managed to debug test_polymorphic_archive_polymorphic_xml_warchive.exe . Memory access violation error is thrown inside basic_ofstream::~basic_ofstream(), called at line 43 of test_polymorphic_archive.cpp (closing scope) ie. when destroying some automatic variable created in this code: { test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa_implementation(os); boost::archive::polymorphic_oarchive & oa_interface = oa_implementation; oa_interface << BOOST_SERIALIZATION_NVP(d); } Here is simple test program I wrote to reproduce this error: #include <fstream> #include <boost/config.hpp> #include "test_tools.hpp" int main() { const char * testfile = boost::archive::tmpnam(NULL); test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa_implementation(os); printf("boom\n\n"); } B.
participants (3)
-
Bronek Kozicki
-
David Abrahams
-
Robert Ramey