[serialization] Notes from a new boost user
I've become very skeptical of my ability to predict how other programmers are going to address things. I'm willing to wait and see.
So I'm anxious to see where this goes. If in fact we do get a wave of users with problems, I'll be forced to modify my point of view in the face of the facts. If (almost) no one complains (perhaps unlikely) then there will be no issue. If there are a fair number of complaints - but it turns out that a significant portion are due to real mistakes - we might be in for another debate. But given more data, I would expect it to be of a different character. If it turns out (almost) none of the cases are real problems, then I'll have to accept as a fact that its a bad idea.
As a new boost user I thought I would humbly submit some feedback. Forgive me if I missed nuances of the existing debates. 1) I love the serialization library, I'm sure many of us have done similar code before, and it's great to see work towards a standardized solution. Really useful, thanks Robert! 2) The new "const required to save" restriction bit me, took a day or two to work through the mailing list and #boost to figure out the problem. Is there a way to make the end-of-the-chain error message (`boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value') more clear? I would rate the severity of the difficulty a 2 or 3 out of 10, from a new user's perspective. It seemed intuitive enough once I understood the requirement. Putting the serialization save calls within a const save(archive) function of the object being serialized made it a non-issue for me. I haven't used it enough to say I won't run into the const issue again, but at least I know about it now. 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? As I've said, I'm brand new at this. I'm providing this feedback for two reasons: to give you an idea of what I ran into as a new user, and to get suggestions on anything I'm approaching in the wrong way. Thanks again boost.
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?
for saving/loading. (I sent Robert the code. He didn't have a chance to answer, yet. The code works for me, but I think it's not yet complete. If Robert thinks it is useful then we'll publish it here.) 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
I think this approach is viable. However, I also think a different approach could be better: using a Serialization Wrapper. With a wrapper you're still be able to use the "ar &" notation while the wrapper itself can split into load/save functions. I recently discovered that (I'm a new user of Boost.Serialization myself) while trying to write code that reuses operator << and operator 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? Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
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
participants (3)
-
Martin Wille -
Michael Behrns-Miller -
Robert Ramey