Jarl Lindrud wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
That is not relevant. The ar >> and ar << don't have to be in the same program. They just have to be consistent with each other.
Thanks for the clarification. So the program in the OP (let me call it A0 :) ), is a valid test case then, and a simpler one at that, than A1, A2 and B.
In the IPC case, the program could only occur when the recieving program is a later version of the sending version. That is the same problem - reading an old archive version.
Well, the problem also manifests in single programs, as A0 indicates. There's no versioning going on there.
This program contains a dummy function whose only purpose is to illustrate a problem that could occur under very infrequent circumstances. Whether or not it should be characterised as a valid usage of the library is a question I'll leave unaddressed. Basically there were and are three options here. a) include class information for all types inside of all archives. b) eliminate the option "track_selectively" c) do nothing. There are trade-offs associated with each option. Given the trade-offs, I still believe that c) is the best choice. And I also believe most people with a good understanding of these trade-offs would agree with me. Having said that I'm considering emitting a compile time warning for types to which all the following apply a) use "track_selectively" b) don't store class data in the archive c) serialialize through a pointer. This warning wouldn't come up very often, (though it would in your test case) and almost all the time it would be spurious. It would be legitimate only in my previous versioning example and your test case. So then I would have to explain what this means either in the documentation or repeatedly on this list - probably both. Then someone would (legitimately) want to be able to turn it off. So even this "simple" idea entails a lot of work. I've also considered - as I have in the past - emitting a compiler time error if versioning is used on type which doesn't store class information in the archive. I tried this before but I couldn't get it implemented without creating other problems - but I think I might have method now. This is only peripheraly related to this discussion, I just mention it so that no one will think this is a total waste of time. Robert Ramey
Regards, Jarl.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost