[serialization] mac/windows difference
I have a test program (boost::test) for a set of my application classes. When run on darwin (10.4.6, gcc4.01) the tests work correctly - that is, I can serialize the structure to an XML archive and read it back (actually, all 3 archive types). When I run the same test on windows (XP sp2, vc8), the read back of the XML archive fails very early because it apparently can't find an appropriate class to instantiate. When I look at the XML output, the windows version has a class name at the point where it fails, while the darwin version does not (there are NO class names written in the darwin archive). The code between darwin and windows is essentially the same - there aren't any differences in MY code in the serialization code. Several points: a) The topmost level is a pointer (plain) to an abstract class - the concrete subclass being serialized is very simple at this point. b) The specific class that's failing is from an STL map with pointers to an abstract base class. 1) That particular failing class is successfully tested prior to where it fails in the same test application (output to all archive types and read-back). 2) although it's using a different archive to test, initialization of all archives is identical (register_type and register_void_pointer called as appropriate) c) There is one other class that also gets serialized with a class name in addition to it's ID (I presume this means that something's up with class registration?) Ok - any suggestions on how to tackle this? I can't find anything wrong in the registration (i've walked through my part of the registration code in the debugger). I'm using boost 1.33.1 Thanks Hugh Hoover Enumclaw Software
Hugh Hoover wrote:
I have a test program (boost::test) for a set of my application classes. When run on darwin (10.4.6, gcc4.01) the tests work correctly - that is, I can serialize the structure to an XML archive and read it back (actually, all 3 archive types). When I run the same test on windows (XP sp2, vc8), the read back of the XML archive fails very early because it apparently can't find an appropriate class to instantiate.
Its not clear what you're doing here. Is the second test reading the archive created by the first test on a different machine or is it reading an archive created on the same machine?
When I look at the XML output, the windows version has a class name at the point where it fails, while the darwin version does not (there are NO class names written in the darwin archive).
The should look identical.
The code between darwin and windows is essentially the same - there aren't any differences in MY code in the serialization code.
Hmmm - "essentially" ? - why is the code not identical? Is BOOST_CLASS_EXPORT used in the second test - that is where the class names come from.
Several points: a) The topmost level is a pointer (plain) to an abstract class - the concrete subclass being serialized is very simple at this point. b) The specific class that's failing is from an STL map with pointers to an abstract base class.
The class thats failing is the STL map or is it a member of the map?
1) That particular failing class is successfully tested prior to where it fails in the same test application (output to all archive types and read-back). 2) although it's using a different archive to test, initialization of all archives is identical (register_type and register_void_pointer called as appropriate) c) There is one other class that also gets serialized with a class name in addition to it's ID (I presume this means that something's up with class registration?)
Ok - any suggestions on how to tackle this? I can't find anything wrong in the registration (i've walked through my part of the registration code in the debugger).
I would suggest posting a small example which we can run. Robert Ramey
I'm using boost 1.33.1
Thanks
Hugh Hoover Enumclaw Software
On Jun 15, 2006, at 22:33, Robert Ramey wrote:
Hugh Hoover wrote:
Its not clear what you're doing here. Is the second test reading the archive created by the first test on a different machine or is it reading an archive created on the same machine?
A structure is serialized to an ostringstream, then the string used to create an istringstream and read back immediately.
The code between darwin and windows is essentially the same - there aren't any differences in MY code in the serialization code.
Hmmm - "essentially" ? - why is the code not identical?
acquisition of UUID's from the system, as well as the library used for MD5 digests - both of these are indirected through other classes, but most of that (#ifdef) code is inline, so technically.... I don't believe the differences have anything to do with the problem - by the time serialization is done, all of that code has done it's job long before, and no issues have shown up in testing on either platform.
Is BOOST_CLASS_EXPORT used in the second test - that is where the class names come from.
BOOST_CLASS_EXPORT is used in all cases - along with some registration functions that call register_type and register_void_pointer for my serializable classes.
b) The specific class that's failing is from an STL map with pointers to an abstract base class.
The class thats failing is the STL map or is it a member of the map?
Not the map - it's clear it's failing on the second part of the pairs stored in the map, i.e., the value part of the the key->value pair.
Ok - any suggestions on how to tackle this? I can't find anything wrong in the registration (i've walked through my part of the registration code in the debugger).
I would suggest posting a small example which we can run.
I was afraid of that - I didn't run into this until I got into the full set of classes... I've been building this up from the basic classes to the higher level ones (testing each class along the way). Everything has been working fine up to this point. The curious thing (to me anyway) is that I successfully, IN THE SAME TEST PROGRAM, write and read back ALL of the concerned (contained or referenced) classes prior to the test that fails, which adds one further level to the structure. I can also write and read back an
empty< instance of THAT structure with no problem.
Well - if I can't figure this out in the next day or two - I'll try to build some test classes that show the problem.
Hubert Hoover wrote:
Hmmm - "essentially" ? - why is the code not identical?
acquisition of UUID's from the system, as well as the library used for MD5 digests - both of these are indirected through other classes, but most of that (#ifdef) code is inline, so technically.... I don't believe the differences have anything to do with the problem - by the time serialization is done, all of that code has done it's job long before, and no issues have shown up in testing on either platform.
Note that default serialization of pointers has some non-obvious optimizing behavior which might be affection things. If and object is never serialized as a pointer, it is not "registered" in the archive so the class name won't appear. Also, if an type is used directly before being used as a pointer, it is already "known" by the archive so there is no need to include the class name. I'm wondering of the "essential" changes could be having this subtle side effect. But even so, I would expect that in all cases an archive produced on the system could be read back without problem. You might make a small serialization test program and add to it until it fails.
BOOST_CLASS_EXPORT is used in all cases - along with some registration functions that call register_type and register_void_pointer for my serializable classes.
Hmm - if BOOST_CLASS_EXPORT is being used in all classes and register type is also being used, that might create some confusion. If register_type is being used, then the class name is not needed by the archive and is not included. Try commenting out all the register_type invocations. Note that explicit invocation of register_void_pointer should be necessary only in the most rare occasions. The only one that has occurred to me is where the abstract base calss contains no serialization function of its own. Robert Ramey
participants (3)
-
Hubert Hoover -
Hugh Hoover
-
Robert Ramey