operators << and >> on boost serialization
Ok!
I'm starting to freaking out, because I just can't figure it out some
compilation errors when trying to use the boost serialization library.
I just can't manage what I'm doing wrong.
Ok, I think that the best way to translate my problem is to post the
code and the changes I'm trying to do:
So ans as you can see on the attached file:
My project and all of my classes are inside a namespace the FlowEngine.
I have 3 classes: A; B and C to test the boost serialization.
As it is now it compiles and runs good.
But I take the comments of class A to split member serialization, just
doing that I get this errors when compiling:
\3rdparty\include\boost\serialization\access.hpp(93) : error C2662:
'void FlowEngine::A::save<Archive>(Archive &,const unsigned int)' :
cannot convert 'this' pointer from 'const FlowEngine::A' to
'FlowEngine::A &'
with
[
Archive=boost::archive::text_oarchive
]
Conversion loses qualifiers
\3rdparty\include\boost\serialization\split_member.hpp(43) : see
reference to function template instantiation 'void
boost::serialization::access::member_save
Miguel Silvestre wrote:
Ok! I'm starting to freaking out, because I just can't figure it out some compilation errors when trying to use the boost serialization library.
Try looking at the "rationale" section of the documentation which describes the issues related to serialization of non-const data. Robert Ramey
Robert Ramey wrote:
Miguel Silvestre wrote:
Ok! I'm starting to freaking out, because I just can't figure it out some compilation errors when trying to use the boost serialization library.
Try looking at the "rationale" section of the documentation which describes the issues related to serialization of non-const data.
Please change the serialization library s.t. one can serialize non-const data. This problem reappears again and again for users, *even for experienced users*. Then provide a macro a la BOOST_SERIALIZATION_STRICT_CONSTNESS_REQUIRED for those who want the current behavior. cheers Thorsten
Thanks a lot!
A simple const in the save function resolved all my troubles :S. How could
it be???
I was in two days just beating my head over the wall :P
On 1/8/07, Thorsten Ottosen
Robert Ramey wrote:
Miguel Silvestre wrote:
Ok! I'm starting to freaking out, because I just can't figure it out some compilation errors when trying to use the boost serialization library.
Try looking at the "rationale" section of the documentation which describes the issues related to serialization of non-const data.
Please change the serialization library s.t. one can serialize non-const data.
This problem reappears again and again for users, *even for experienced users*.
Then provide a macro a la BOOST_SERIALIZATION_STRICT_CONSTNESS_REQUIRED for those who want the current behavior.
cheers
Thorsten _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Miguel Silvestre
Hmmm - two days! - reading the docs would take a lot less than that. The
rationale gives a detailed explanation of how much time you could lose from
not being aware of some subtle issues regarding tracking. Also, the stack
trace points to a comment in the code which describes the issue. With VC
8.0 all it takes is a double click on the error message in the stack trace
to bring up the associated code.
So, I'm sorry you had to spend so much time on this. Hopefully, this
excersize wil save much more
pain in the future.
Robert Ramey
"Miguel Silvestre"
Miguel Silvestre wrote:
Ok! I'm starting to freaking out, because I just can't figure it out some compilation errors when trying to use the boost serialization library.
Try looking at the "rationale" section of the documentation which describes the issues related to serialization of non-const data.
Please change the serialization library s.t. one can serialize non-const data. This problem reappears again and again for users, *even for experienced users*. Then provide a macro a la BOOST_SERIALIZATION_STRICT_CONSTNESS_REQUIRED for those who want the current behavior. cheers Thorsten _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Miguel Silvestre _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Since we've implemented this we do get a complaint on a regular basis - but we've not had a problem which had cropped up a couple of times before - creation of archives which cannot be read. For those that use "const" on a regular basis this issue hardly every crops up. To accomodate the rest of us I might be convinced to implement: BOOST_SERIALIZATION_NO_CONST_CHECKING which would suppress the check. This would help those who have an issue with using "const" but it wouldn't cut down the frequency of the incidences such as that started this thread. Robert Ramey Thorsten Ottosen wrote:
This problem reappears again and again for users, *even for experienced users*.
Then provide a macro a la BOOST_SERIALIZATION_STRICT_CONSTNESS_REQUIRED for those who want the current behavior.
cheers
Thorsten
Robert Ramey wrote:
Since we've implemented this we do get a complaint on a regular basis - but we've not had a problem which had cropped up a couple of times before - creation of archives which cannot be read.
For those that use "const" on a regular basis this issue hardly every crops up. To accomodate the rest of us I might be convinced to implement:
BOOST_SERIALIZATION_NO_CONST_CHECKING which would suppress the check. This would help those who have an issue with using "const" but it wouldn't cut down the frequency of the incidences such as that started this thread.
Hm. I have a certain feeling that the "trap" is somewhat misplaced. First of, any solution that is **so** complicated to explain as http://www.boost.org/libs/serialization/doc/rationale.html#trap tells my intuition that something is not clearly understood yet. Question: what is the real problem here? Is it that one programmer serializes an object and another a pointer? Probably not. Could it be this: the default tracking behavior is "track_selectively". Possibly. Your looong example ends with this text: "Eventually, after some code restructuring, the differing requirements of serializating construct_from are reconciled." But what do the programmers end up doing? I'm very curious? Is it not possible to what the programmers in the example is trying? (I'm too stupid here, but I thought it might be possible!) Anyway, it might be worth considering this procedure: 1. There is no default tracking level. It must be set explxitly for all classes. It should be part of a class' public interface that you know it is serializable and that you know *explicitly* what tracking it supports. Maybe this can be implemented as a macro that must expand inside the class, so it can only be provided with the declaration of the class. AFAICT (*), with that in place, there is not need for "traps". cheers -Thosten (*) It's been a long day of 10 hours work and 3 hours helping my big-brother with marketing assignment, so my brain might not work properly anymore :-)
Thorsten Ottosen wrote:
Hm. I have a certain feeling that the "trap" is somewhat misplaced.
First of, any solution that is **so** complicated to explain as http://www.boost.org/libs/serialization/doc/rationale.html#trap tells my intuition that something is not clearly understood yet.
Question: what is the real problem here?
Could it be this: the default tracking behavior is "track_selectively". Possibly.
That's it. This would be the behavior that I would expect most programmer's desire. That's why I made it the default. But (like other cases where a default is used), it can create unintended side effects. Hence the trap to make at least one such side effect visible.
Your looong example ends with this text: "Eventually, after some code restructuring, the differing requirements of serializating construct_from are reconciled."
But what do the programmers end up doing? I'm very curious? Is it not possible to what the programmers in the example is trying? (I'm too stupid here, but I thought it might be possible!)
Basically serializing through a pointer requires tracking to guarentee that that the de-serialized structure replicates the original. So serialization through a pointer conflicts with tracking turned off. One programmer has trackng turned off to make a log entry while another needs to serialize a pointer to an instance of the such an entry. There are a number of ways to handle this. a) they could arm wrestle and the loser changes his code. b) they could define different types - perhaps with a common base class. This would allow different attributes in each usage. c) some other way that hasn't occured to me.
Anyway, it might be worth considering this procedure:
1. There is no default tracking level. It must be set explxitly for all classes. It should be part of a class' public interface that you know it is serializable and that you know *explicitly* what tracking it supports.
Maybe this can be implemented as a macro that must expand inside the class, so it can only be provided with the declaration of the class.
This would require that one have access to the class definition inorder to serialize an instance. Thus one of the main requirements of the library would have to be set aside. This is essential to things like defining serialization.
AFAICT (*), with that in place, there is not need for "traps".
You're probably correct here. In this case, the second programmer changes the tracking behavior and breaks the others code at compile time. (similar to what we have now - but more obvious) Still we would have to explain why this happens - no net gain in my view. This is really a question about the usage of defaults and automatic behavior in general. The function of such default/automatic behavior is to make something easier to use correctly. But taken too far it can lead to opaque behavior that is hard to understand and modify. In my opinion BJAM suffers from this. In this case, I think after all this time that the usage of default settings as well as the settings themselves are "about right". Given how complex the library can/could be to use, its amazing to me that so few issues come up. Robert Ramey
Robert Ramey wrote:
Thorsten Ottosen wrote:
Anyway, it might be worth considering this procedure:
1. There is no default tracking level. It must be set explxitly for all classes. It should be part of a class' public interface that you know it is serializable and that you know *explicitly* what tracking it supports.
Maybe this can be implemented as a macro that must expand inside the class, so it can only be provided with the declaration of the class.
This would require that one have access to the class definition inorder to serialize an instance. Thus one of the main requirements of the library would have to be set aside. This is essential to things like defining serialization.
Well, it could be made such the macros that work outside the class, check the class for presence of the internal macro.
AFAICT (*), with that in place, there is not need for "traps".
You're probably correct here. In this case, the second programmer changes the tracking behavior and breaks the others code at compile time. (similar to what we have now - but more obvious) Still we would have to explain why this happens - no net gain in my view.
Well, wouldn't it mean that we could get the error to point at the macro-definition, instead of some obscure place? (It is really hard to grasp why using a const-cast is really needed ... the connection is just to weak). -Thorsten
Thorsten Ottosen wrote:
Robert Ramey wrote: (It is really hard to grasp why using a const-cast is really needed ... the connection is just to weak).
Actually, this is probably the heart of the problem. Regeneration of serialized pointers has a number of implications which are not at all obvious until you think about it. Among others is the fact that tracking is required to implement this and that this conflicts with other natural usages of serialization. The "real" solution would be cut down the functionality of the serialization to narrow its application to a set of usages which can't conflict. It's also possible that the "serialization traits" might have been designed differently to make eliminate that they be "in sync" or that other higher level traits might be designed instead (e.g. "log", etc....). Its also possible that implementation of a well crafted set of serialization "concepts" could be helpful. So I'm not totally unsympathetic to the complaints about this. And I do concede that it is slightly odd. Recognize that the current solution does in fact address a real problem and does force users to understand their choices in their usage of the library at the time when it can actually help rather than way after its too late. On the other hand, I suspect that this is a problem mostly for people who are not in the habit of using "const" everywhere they can. For those that are in this habit, the problem rarely comes up and when it does its easy to address. For those who aren't in this habit - it requires some sort of "ugly" casting. I confess I don't have much sympathy here. Why should the rest of us give up a useful double check just because other's don't use "const" enough. For those that don't agree - well, they always have the & operator to fall back on. In the context of an archive, this is identical to an << or >> without the "trap" Robert Ramey
-Thorsten
participants (3)
-
Miguel Silvestre -
Robert Ramey -
Thorsten Ottosen