Hello, Neal D. Becker wrote:
I don't see unload/reload as a requirement. I think this use case would be pretty obscure. What semantics would you even expect in that case?
Actually, one of the reasons I invested time to make serialization work in DLL form and with serialization code in user DLLs was exactly because we have DLLs that are loaded/unloaded explicitly at runtime. A typical example could be a server that loads specific plugin modules during runtime (and can unload them again). Or in our case, we have a plugin for 3ds max that uses boost::serialization to write out data for our main application. 3ds max plugins must support dynamic loading/unloading during runtime. The semantics I expect in this case is that the classes in the newly loaded DLL that have serialization code register their extended type info with the global boost::serialization type registry, and upon unloading unregister it again. We've been using our modified version of boost::serialization ever since the draft release #18 in a rather large software system that consists of a large number of DLLs (all with serialization code, of which some are dynamically loaded/unloaded during runtime), and haven't had any major problems with it so far. Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at