Robert, Thanks for your quick reply.
Indeed it would. I want to review the implementation of boost::shared_ptr in light of recent observations. The other ones will have to be done by someone else. Since you have a need/interest in this, perhaps you would like to do this and send it too me?
The serialization of boost::shared_array should, in principle at least, be very similar to boost::shared_ptr. So once a good solution is found for boost::shared_ptr, I believe, it can be applied to serialize boost::shared_array as well. As for other smart pointers, I think that a lot of serialization code can be used from the code for boost::shared_ptr. In any case, I do not yet know enough about the internal structure of boost::serialization to impelement smart pointer serialization myself. But if I find the time I will look into it, but I can't promise anything. While on the topic, the current shared_ptr serialization code gives an access violation when deserializing an empty shared_ptr. To remedy this in the class shared_ptr_access the following code static void add_ref_copy(boost::detail::sp_counted_base * t){ t->add_ref_copy(); }; should be changed to check for a non-NULL pointer to the counter: static void add_ref_copy(boost::detail::sp_counted_base * t){ if (t) t->add_ref_copy(); };
Is there work under way to fix this and have working DLL builds of boost::serialization (just as there are DLL builds for, say, boost::regex)?
I have interest in addressing this. I do believe it is addressable without too much difficulty but will require some extra care. There also might be some restrictions on usage - I don't know yet.
I looked into this some more and I believe to have found somewhat of a solution (albeit a "hacky" one) for the template classes derived from extended_type_info. If you don't mind I will send you my current boost::serialization code base via private e-mail and you could maybe have a look at it. As I wrote above, I do not yet know enough about the internal structure of the library, so I can't say for sure if my changes broke anything major. In the limited tests I did with the demo samples that come with the library everything seemed to work fine though. One thing that I have not yet addressed though is the need for extended type info objects to unregister themselves from the global registry. This is important when DLLs are loaded, unloaded, and then loaded again. I believe this should be quite easy to implement. Simply make a call to some unregister function in the extended_type_info destructor, similar to the self_register call in the constructor. This actually brings me to another question: Why is the self_register call not directly in the base class constructor, i.e. in extended_type_info::extended_type_info, but rather in the deriving classes?
My intention was the BOOST_CLASS_EXPORT be included in the header file.
I don't quite understand how this can work reliably. Say, I have two DLLs. In one DLL I have class A. A's header file also contains the BOOST_CLASS_EXPORT(A) macro. Now a second DLL also needs to use this class. Therefore it will include A's header file. This will result in a static guid_initializer instance to be created in both DLLs, which is unnecessary. Also with the current code it will cause the class' extended type info to be registered twice, once in each DLL with a different extended type info object each time. I believe my code modifications will remedy this though, so it wouldn't matter if the registration happened multiple times, but it is still unnecessary. The only "proper" way I know of to avoid this is to always use the export macros in .cpp files.
This would mean code modules would be organized similar to the demo_pimpl example where the implementation of class serialization (invocations of ar << my_class_instance) are in separate modules from the headers rather than inline functions.
I've looked at that sample, but since we are trying to integrate boost::serialization into an existing project, reorganizing all of our code is pretty much out of the question. We tend to have the serialization code inlined in the header files of the class it belongs to. This has so far proven to be good for maintenance of the code as well (e.g. when a new member variable is added to a class it is harder to forget to also change the serialization code, if necessary). Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at