Vladimir Prus wrote:
Robert Ramey wrote:
Are you sure this worked before? That would surprise me.
Absolutely. This worked for about half an year ;-)
Well, I can't explain it - oh well
Yes, I see -- with the current implementation. Maybe, you changed the implementation recently?
I'm sure I have - but I can' t imagine how something like this would happen. I'll look in to it.
My suggestion would be to include the archive headers only in the modules that actually invoke serialization. And that be only in one module. My intention was that each class header contain BOOST_CLASS_EXPORT for its classes and the the "main" or other module (see demo_pimpl) that actually invoked the serialiation would include the headers for the archive classes that are desired. This makes it easy to switch between archive types for things like debugging, etc.
This is fragile. If I have two modules, linked in one application, which both use serialization, then if they both include a single header with BOOST_CLASS_EXPORT, I'll get link error, right? I don't think it's realistic to expect that either: 1. Classes are serialized only in one module. 2. No header file is used by more that one module.
Not quite. Header containing the serialization can be specified all over the place as many times as one wants. Its the combination if archve and serializaition which would appear in only one module. The pimpl example sort of illustrates how I would imagine would be a practical way of doing this: a) include BOOST_CLASS_EXPORT(C) in c.hpp b) make a module c.cpp which implements serialization for all the archives you plan to use c) build the c.cpp with granularity to the function level (the requires /Gy on microsoft platforms) d) compile c.cpp to the library. e) your "main" application can import the header c.hpp f) you link step will include the code corresponding to the combinations of archive/serialable classes that you actually have used. Once things are organized in this way you can add/delete code and headers from your "main" app as you wish and everything is taken care of automatically It gets better. If you follow the above scenario you can compile the serialization implemention modules to DLLS so that the code only gets loaded when used at runtime. It gets even better. If you follow the above and compile your serializaition modules as DLLS and use the polymorphic archive. You'll be able to update your main application and even use archive classes yet to be implemented. Even better yet. If the "main" code serializes a pointer to a base class, and a new derived class is built as a DLL, this new class can be dynamically loaded even by an older program - plugin capability. All these thiings are contemplated in the code for the current library. The last (plugins) hasn't yet been tested. And doing so will likely generate some changes / bug fixes in the library. But it has been done by Martin Ecker in his own customized version of this library. I've basically incorporated his suggestions in accordance with boost requirements.
In my case, I've moved BOOST_CLASS_EXPORT to an implementation file and it worked. I am not sure this solution is generally applicable -- one might want header-only class hierarchy...
I know people have had some problems with this in the past. I believe I've got this under control - but I don't know for sure. Note that the instantiation model for C++ has variations across implementations. In building the static and DLL versions of the library I found the simplest and most reliable way to deal with the variety of platforms was to explicitly instantiate the code I wanted. This turned out not to be a problem as I had expected. I just instantiate all combinations and include them in the library and let the linker select what it want's to use. Crude perhaps, but very effective. It also has the very convenient aspect that it greatly lowers build times and forces a more robust code factoring. Also I forgot to mention, there is always the posibiity of setting the linker switches so taht duplicate symbols are not flaged as errors. I believe that this can work, but its too big a hammer for my taste. Robert Ramey