Vladimir Prus wrote: >> iii) requirement to pre-register classes to be saved as pointers >> through a base class
>Was it ever considered a problem. You surely have to register a class in >order to deserialize it (Java can create a class given its name, but we're >in C++). I refering to the issue of "forward declaration" vs "module level registration" We spent a quite of bit of time on this as well as type_info, etc. I have added the "module level registration which I think would satisfy the concerns you raised and conflict with my concerns. But I want to pass through it one more time to unitify the treatment of external type ids. This is in part inspired by G Rozenthal's concern that RTTI should not be required. I don't really share the concern. But if things are factored in the right way the external type id issue becomes a replaceable component and we won't have to spend a lot of time on the issue. >> iv) requirement to have separt save/load code for serialization functions >I though about it just recently, and stubmled upon the issue of >const-correctness. Probably, separate save/load is OK, since I don't know >any good alternative solution. I was always a fan of "const-correctness" that came with the save/load system. Also the save/load system permitted a finer granularity such that a program that only read would only have to import half the headers and library code. (Same for programs that only write archives). However, I was sensitive to the redundance of the save/load system and came to appreciate the usage of the & operator for both saving an loading - even at the cost of const - correctness. (thanks to jens maurers effort) After trying out a number of alternatives I came to a solution which permits either to be used on a class by class basis. >Can we have a look at it? Probably, putting it to boost-sandbox is good >idea. I'm really interested to see how it applies to use case I have at >hand. I don't feel its quite ready for that. Some things are still in the experimental stage and I'm still weighng alternatives. After these things are settled I would better be able to provide explanations for the choices I made. Please send me your use case. I am very interested in it. Hopefully soon I will have the package working at the level I desire. Then there's a huge amount of work (re)writing and expanding the documentation and finer granularity test cases. oh then there's the jam build. and then making things work on more compilers,etc. In all its a very large job. So my preferred plan would be: a) finish what I'm doing as far as features are concerned b) expand documentation a minium amount c) expand test cases a minimum amont d) send it privately to boosters who have shown a special interest in this package e) make some more changes f) If there's still interest, upload it to CVS g) see what happens. This would still be a couple of months away. > b) versioning at the class level > >It would be nice, BTW, to have optional versioning.... The question about "optionality" features is much more intricate than it first appears. Other features that are candidates for optionality are: a) serialization of pointers b) versioning c) tracking of object addresses to eliminate extraneous copies d) bypassing the serialization system for special cases and some of these features interact with each other. After much experimentation I have made a system which permits selection of optional serialization features on a per class basis. It turns out that ALL the issues raised in the review, including those that I dismissed, are being addressed. I didn't really intend to do this I had resolved to improve the quality of the implementation and leave most of the feature decisions unchanged as I saw them as ireconcilable trade offs. I was much surprised to discover that improving the implementation made apparent that what I had thought were trade offs where in fact artifacts of implementation stratagy decisions. Note to potential library submitters: The boost review process is far more rigorous than what one is normally accustomed to and I suspect that few are really prepared for it. On the other hand, I have no doubt that this the reason for the incredible high quality and utility of the boost libraries. The only thing I can't explain why anyone would subject himself to this. Yet here I am. oh well. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
