Re: [Boost-users] Boost serialisation: base ptr regression in 1.42

The warning messages have gone when I used a const object. Thanks. However the "*unregistered class* " crash still remains if the if base/derived classes are placed in a static lib. (for 1.42 only). Robert Ramey wrote:
EXPORT has been made a little bit more elabort to separate issues of code instantiation for class registration. These changes were necessary to make EXPORT work properly with DLLS. Look at the 1.42 documentation for an explanation.
Not sure I understand this. In the 1.42 documentation under "Export Key" it says: "For programs which consist of only one module - that is programs which do not use DLLS, one can specify BOOST_CLASS_EXPORT(my_class) or BOOST_CLASS_EXPORT_GUID(my_class, "my_class_external_identifier") in either he* declaration header or definition*. These macros expand to invocation of the of both of the macros described above. *(GUID stands for Globally Unique IDentfier.)" * So I am not using DLL's, and have used BOOST_CLASS_EXPORT(Derived); in the implementation class. So the work around for unix's looks like: 1/ Place the BOOST_CLASS_EXPORT in the implementation and use explicit type registration 2/ Place the BOOST_CLASS_EXPORT in the header *_only_* In either case this is significant change, and should merit mention in the 1.42 release notes, and a change to the documentation Best regards, Ta, Avi

Avi Bahra wrote:
So I am not using DLL's, and have used BOOST_CLASS_EXPORT(Derived); in the implementation class.
So the work around for unix's looks like: 1/ Place the BOOST_CLASS_EXPORT in the implementation and use explicit type registration
I don't think ...EXPORT should be required with explicity type registration. Please check this.
2/ Place the BOOST_CLASS_EXPORT in the header _only_
In your case, I don't think placing ...EXPORT in the implemenation would hurt. Putting it in the header implicitly puts it into the implementation anyway since the implemenation includes the header.
In either case this is significant change, and should merit mention in the 1.42 release notes, and a change to the documentation
Hmmm - I was sure that I enhanced the documentation to explain this. I'll double check. Robert Ramey
participants (2)
-
Avi Bahra
-
Robert Ramey