| 1 | | I've read your last comment, and it seems to make sense if I switch the two code blocks (and add make it pph.m_ph = '''&'''ph.) Is this what you intended? |
| 2 | | |
| 3 | | Assuming it is, I believe the code in the first block was well behaved in 1.53 and prior versions. Otherwise we would have seen this issue in our own archives which apparently do a lot of this. I have a version of 1.53 handy so I can test it tomorrow. |
| 4 | | |
| 5 | | I agree the fix I proposed is specific to the all heap allocated case. I don't think there is a general solution which handles both of these use cases. My understanding of the library is that whenever a pointer is serialized, it will be heap allocated on the read unless it is tracked and has already been loaded (in which case it will simply assign the previously loaded value.) In order to support consistency between pointers to a stack allocated object, there would have to be something to tell the archive that the original stack allocated object's address needs to be tracked. I could imagine a wrapper for it which tells the archive to put the address into the pointer tracking system (something along those lines.) That might work, maybe it's worth a discussion with other users on the list. |
| 6 | | |
| 7 | | Still, IMO the stack allocated case seems less likely than the heap case. Perhaps it makes sense to fix the heap case and add documentation about the issue with serialization of pointers to stack allocated objects that informs that cycles would be broken on deserialization in those instances. |
| 8 | | |
| | 1 | Edit: after learning about BOOST_CLASS_TRACKING, the earlier comment made no sense. ;) |
