Manos Tsagarakis wrote:
Hello Robert,
Thank you for the quick response.
I'm glad you liked the title ...
A) I did replace all BOOST_CLASS_EXPORT with BOOST_CLASS_EXPORT_GUID, but the problem with xml persists. It is really difficult for me to figure out what is wrong with xml, as both txt and bin versions are ok. Actually what worries me, is the possibility that the problem with xml somehow will show up in other formats too ...
I not sure that the exported name can have a ':' in it without tripping up XML If that's not it I'm not sure what it is.
B) I don't use the version numbers at the moment but I added it just for future use. I actually have a couple of questions here. 1) BOOST_CLASS_VERSION has to be in the header file? Can I place it in the cpp file? 2) Please correct me If I'm wrong: I don't use BOOST_CLASS_VERSION so that all classes have version number assignment set to 0. I also don't use BOOST_SERIALIZATION_SPLIT_MEMBER for now. Later on, I add some members, so that the class version must change. I simply add BOOST_CLASS_VERSION(..., 1) and split serialize to save/load at that time. Previously saved data files are not affected as long as version info is handled correctly by my code. Is that correct?
Correct - BTW you don't necessarily have to split but in many cases it would be the easiest thing to do..
C) I avoid using templated code in CTCDataBase for as long as the core data that must be serialized evolve, in order to avoid frequently modification of the most included header file TC_database.h. That meens almost recompile all, and that takes time. Thank you for the suggestion any way. I'll keep it in mind. To be honest, I did try to use export feature of templates bug no luck ...
The way to do it is to leave the template definition in a header and an explicity instanticiation in a *.cpp file. That is how the serialization library diminishes compilation.
D) I re-attach a couple of header files to this post and I kindly ask you to take a look at the implementation and tracking level for template class fem::CPropRepository implementation_level< fem::CPropRepository<T, SZ> > and tracking_level< fem::CPropRepository<T, SZ> >, and one utilization of it at the other header. Should it be so? Do I need it? And also is it possible that using this CPropRepository stuff (especially with MFC CString) breaks the xml code?
A fundemental problem here: //either use macro definitions: //BOOST_CLASS_IMPLEMENTATION(nvp<T>, boost::serialization::level_type::object_serializable) //BOOST_CLASS_TRACKING(nvp<T>, boost::serialization::track_never) the arguments can't be templates but must be expanded types. This is described in the manual - I forget where. If you need this functionality, you can't use the macro. You have to copy the original definition and make the substitution by hand. If you look at the macro definition and "expand it by hand" you'll see that it won't result in valid code.
E) After adding all headers of the serialize library compilation takes a lot more time. Are there any guidelines by you on that?
Here's what I recommend. Look at the demo/example/test demo_pimpl. This shows how one can separate the instantiated serialization code into a separate *.cpp module. This will mean that its only compiled when the serialization changes. In fact the best way is to add all the *.cpp modules for all archives in a library. That way they are almost never compiled and executables only contain the stuff actually used. Robert Ramey