[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.
Thanks for your feed back. 3) is_saving and is_loading are already in the library. I'm sure they're documented in the 1.33 version and I thought they are documented in the 1.32 version but I'll double check. Robert Ramey Michael Behrns-Miller wrote:
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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Michael Behrns-Miller" <m@thedigitalmachine.com> writes:
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
Did it prevent a bug, or did it just cost you 2 days of your valuable time? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Michael Behrns-Miller" <m@thedigitalmachine.com> writes:
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
Did it prevent a bug, or did it just cost you 2 days of your valuable time?
Were you not tempted to just use "const_cast"? Why not? Robert Ramey
Michael Behrns-Miller wrote:
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.
This is something other people has asked for but we've never been able to figure out how to implement it. Whenever I do include a BOOST_STATIC_ASSERT that a library user might be expected to trip on, I include comments at that point which describes the problem and hopefully a helpful course of action. When I build in my environment (VC 7.1) and double click on the error message, the BOOST_STATIC_ASSERT pops up and right there is the comment explaining it. To me, this seems pretty good and I would hope that this would minimize the time a user has to spend looking for sources to these problems. In fact, I have received mail from users that have remarked upon exactly this feature/practice as being very helpful in understanding these other wise very subtle errors. By far the best one is when one uses an xml_archive to serialize something which doesn't have a variable name attached. It pops a STATIC_ASSERT and the comment right there is the comment describing what one is doing wrong. Robert Ramey
participants (3)
-
David Abrahams -
Michael Behrns-Miller -
Robert Ramey