[Serialization] Multiple BOOST_CLASS_EXPORT
Hi, Is there any danger in having multiple BOOST_CLASS_EXPORTs within a shared library or executable? I have a template child class that is always serialized by base class pointer and to keep myself sane I figure I can just blindly add BOOST_CLASS_EXPORT(ChildClass<T>); at the end of the .cpp file that uses it. Thanks, Sohail
This has caused problems in the past. I believe that the code checked into the current HEAD branch of the CVS tree addresses this, but I havn't been able to test it. My intention was the BOOST_CLASS_EXPORT would be included in the *.h file for the class. My recommendation is to make a library which instantiates all your classes's serialize functions with all the archives you're going to use. Then link against this library. Robert Ramey Sohail Somani wrote:
Hi,
Is there any danger in having multiple BOOST_CLASS_EXPORTs within a shared library or executable? I have a template child class that is always serialized by base class pointer and to keep myself sane I figure I can just blindly add BOOST_CLASS_EXPORT(ChildClass<T>); at the end of the .cpp file that uses it.
Thanks,
Sohail
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 26, 2007 9:06 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Serialization] Multiple BOOST_CLASS_EXPORT
This has caused problems in the past. I believe that the code checked into the current HEAD branch of the CVS tree addresses this, but I havn't been able to test it.
My intention was the BOOST_CLASS_EXPORT would be included in the *.h file for the class.
If you have BOOST_CLASS_EXPORT in a header file, doesn't that cause the same problems? If this is what your checkins would fix, then that's understandable. However, this still doesn't help with class templates since you can't know ahead of time what parameters to instantiate the templates with.
My recommendation is to make a library which instantiates all your classes's serialize functions with all the archives you're going to use. Then link against this library.
I am starting to lean towards centralizing all the serialization logic rather than having it local to the relevant classes as you suggest. I prefer locality for obvious reasons. But maybe such a cross-cutting concern should be in a single place. Any thoughts (from serialization users even?) Thanks, Sohail
Sohail Somani wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 26, 2007 9:06 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Serialization] Multiple BOOST_CLASS_EXPORT
This has caused problems in the past. I believe that the code checked into the current HEAD branch of the CVS tree addresses this, but I havn't been able to test it.
My intention was the BOOST_CLASS_EXPORT would be included in the *.h file for the class.
If you have BOOST_CLASS_EXPORT in a header file, doesn't that cause the same problems? If this is what your checkins would fix, then that's understandable.
No - code is only instatiated for archives actually used. So if the usage of an archive is confined to ONE module there are no problems. But this requires instatiating the serialization functions not in the header - that is in "out of line" code. Its quite doable but somewhat annoying. This is a result of the C++ instantiation model. Note that different compilers and linkers do things differently, but I believe that this method works on all of them. Downside you have to explictly instantiate combination of type/archive you might export. So I recommend putting them in a library and linking against that so you don't suffer from code bloat. Finally, you can also use the polymorphic version of the archive. This permits you to compile only one instantiation for all archive types. Linking is accomplished at runtime via a virtual function interface.
I am starting to lean towards centralizing all the serialization logic rather than having it local to the relevant classes as you suggest. I prefer locality for obvious reasons. But maybe such a cross-cutting concern should be in a single place. Any thoughts (from serialization users even?)
It saves a lot of compilation time.
Thanks,
Sohail
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Friday, April 27, 2007 9:47 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Serialization] Multiple BOOST_CLASS_EXPORT
Sohail Somani wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert
If you have BOOST_CLASS_EXPORT in a header file, doesn't that cause the same problems? If this is what your checkins would fix, then that's understandable.
No - code is only instatiated for archives actually used. So if the usage of an archive is confined to ONE module there are no problems. But this requires instatiating the serialization functions not in the header - that is in "out of line" code. Its quite doable but somewhat annoying. This is a result of the C++ instantiation model. Note that different compilers and linkers do things differently, but I believe that this method works on all of them.
Downside you have to explictly instantiate combination of type/archive you might export. So I recommend putting them in a library and linking against that so you don't suffer from code bloat.
Well the way I work is I define the class in the hpp file with template<typename Archive> void serialize(...); Then in the cpp file I do (something like): #include "myclass.hpp" #include "all_my_archives.hpp" #include "export.hpp" template<typename Archive> void MyClass::serialize(...){...} BOOST_CLASS_EXPORT(MyClass); So I think I'm already doing what you suggest as all my classes get compiled once into a single library.
Finally, you can also use the polymorphic version of the archive. This permits you to compile only one instantiation for all archive types. Linking is accomplished at runtime via a virtual function interface.
In time, I think I will do that. Had some issues when I tried to do it earlier but didn't bother to figure them out as I only need a single archive type. Thanks, Sohail
participants (2)
-
Robert Ramey -
Sohail Somani