Martin Wille wrote:
Michael Behrns-Miller wrote:
3) I realize I can split serialize() into separate load/save functions. However, I appreciate the recommendation to use one serialize() function, where the load/save order is easier to maintain. However again, I absolutely need (I think :>) to know, within that function, if I am loading or saving. It's the only way I can efficiently handle versioning or handle dynamic allocations, and still use one serialize() function, as far as I can tell. Bottom line: I now have isSaving(archive)/isLoading(archive) functions, can these be added to the library? Or am I approaching this wrong?
A big advantage of using the "split" functionalty is that its implemented at compile time. So that if you include your class header in a program which does only saving only the code to do the saving will be instantiated. Your programs will be smaller and more efficient (due to the lack of an if(... Note that the library documentation (1.33) does in fact describe is_loading and is_saving boolean contants which can be used to implement trickier serialization. Looking at the split?.hpp files will show one way how these can be used to generate only the required code. Of course they can also be used in the more traditional straight forward way of if(ar.is_loading...) but then your program that do only a save or load will include code they never use. (i.e. code bloat). I believe this will constitute a short excercise in becoming comfortable with template meta-programming as it applies to controling code-bloat.
During the writing, I missed some additional documentation about how to write these wrappers and had to resort to reading the source. Since my understanding of that topic isn't complete, I currently can't contribute the documentation I missed.
Robert (and others), do you think some framework to enable users to write their own wrappers would be useful? (A simple and slow one could use user-provided functors for converting to/from a string.) Could you comment on whether it is desirable to enable users to write their own wrappers?
It has been my intention that wrappers be a "first class" feature of the library. That is available to user of the library. The documentation that's there is written with that intention. So if its incomplete let me know. Having said that, I recently had to add a code in a couple of places to workaround some other inrelated issue. That code is somethin like if type is nvp .... which breaks the independence between nvp and the serialization library itself. Of course nvp IS special but I remember considering adding a trait "is_wrapper" to permit a better indepence of the wrapper concept. I suspect thiis concept ("wrapper") might now be in some need of improvement, clarificatiion and/or repair. But I haven't had time to visit the issue. Robert Ramey