Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-26 01:56:36

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