Matthias Troyer wrote:
On 25 Jul 2010, at 10:28, Robert Ramey wrote:
Matthias Troyer wrote:
Then please demonstrate how to implement an archive that actually does anything sensible and supports pointers, etc. without depending on what you call implementation details. The only way is implementing all the functionality from scratch.
Here's what to do:
a) derive from common archive instead of binary_archive.
I have one more question in addition to my previous comment:
common_oarchive is in namespace archive::detail while basic_binary_oarchive is in the top namespace archive.
Do I understand you correctly that deriving from archive::detail::common_oarchive is safe and not considered depending on implementation details, while deriving from archive::basic_binary_oarchive is not?
I can easily change all the Boost.MPI archives to use archive::detail::common_oarchive where they now use archive::basic_binary_oarchive (although this will not solve the issue we have right now).
I can see where this would be confusing. Let me indicate what I mean of a few of the terms being used. archive concept - minimal concept which states the function interface that an archive class has to support. Doesn't say anything specific about the sematics or functionality.
From this I made some models of this concept. These models implemented behavior that was deemed useful. I factored the implementation of common functionality in a few different places:
base_archive - library code common_archive - library and types needed to implement the desired functionality. interface - iserialzation - common code for user's types. Now when I thought of "user", I was thinking of someone who just an archive already built. I didn't really think of a person making a new archive as a "user". Truth is, I was just factoring code. I put all this stuff in "detail" namespace because I didn't think it was interesting to users. And of course it isn't documented like other stuff is and one might change it because after all it's a "detail". And the stuff in "detail" has it's own "public" and "implemention detail" aspects. For an archive developer who wants to develope an archive with functionality similar to the existing ones, it's not a detail. He wants to know that the public functions aren't going to change. As I've said - I just never thought about this. On the other hand, I don't think the "detail" interface has changed very much (if at all) over time. I can't honestly say I know this - because as I've said - I never thought about it. I suspect that it hasn't changed much because we haven't had much if any breakage originating in this area. So - back to our problem. I had thought the the source of the issue was coupling mpi_archive/skeleton to binary_archive implementation. That's why I thought deriving from common_archive would help. If I'm wrong about the above then deriving mpi_archive from common_archive won't help - though it would probably be a good idea. If the only problem is that version_type eliminated some operations mpi_archive depended on all integer types to have (STRONG_TYPEDEF) this can also be worked out one way or the other without too much difficulty. If all the above is true - this shouldn't be so hard to address. Given that we've had so much difficulty with this, it's possible that one of the above is not true. Finally, you've indicated that an archive writer needs to know the list of internal types in the archive and that they'll never change. This would suggest to me that perhaps a separate section in the documentation describing the "common archive implementation" (text_archive, etc)distinct from other "sample implementations" (trivial archive, simple_log_archive etc.) a description of the functionality of these archives. Basically this supplies the missing "semantics" left undefined by the archive concept. Basically it would list this functionaly, pointers, tracking versioning, etc. common - this implemented special types used internally and their interface. We can discuss whether these types should have the rich interface permited by STRONG_TYPEDEF or a narrow one which is useful for catching coding errors. What is still missing here? Robert Ramey