Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-07-25 12:28:29

Matthias Troyer wrote:
> On 25 Jul 2010, at 00:12, Robert Ramey wrote:
>
>> David Abrahams wrote:
>>> At Fri, 23 Jul 2010 22:30:03 -0800,
>>> Robert Ramey wrote:
>>>>
>>>> Matthias Troyer wrote:
>>>>> On 23 Jul 2010, at 18:11, Robert Ramey wrote:
>>>>>
>>>>>> [snip]
>>>>>> Robert Ramey
>>>>
>>>>> Let me summarize concisely: no user-defined archive type may use
>>>>> any of the serialize function, pointer handling, or any other
>>>>> aspect of the serialization library since all those are
>>>>> implementation details that you might change at any time.
>>>>
>>>> Naturally I think that's a little harsh.
>>>
>>> As far as I can tell there was no criticism, express or implied, in
>>> Matthias's statement, so if it sounds harsh perhaps it is because
>>> the predicament in which he currently finds himself is harsh.
>>
>> It's actually demonstrably incorrect - I was just being diplomatic
>
> 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.  This is
what all the other archives do.  At this level and above there is only
interface and not implemenation.  By doing this you will have total
control of the relationship between the the native types as
represented in memory and those written to to the storage.
The interface at this level hasn't been frozen in any specification -
but as far as I can recall - it's never been changed since the
beginning.

As an aside there is precedent for this.  At one time there was
a section of the documentation. "Deriving from an archive
class". It used binary_archive as a base to create portable
binary archive.  This seemed a good idea at the time.  But
the implementation of binary_archive was changed (by
you actually - though that's beside the point), and this
example broke.  As it was I had just contracted with a
customer to improve binary portable archive - for a flat
fee not less.  I was pretty unhappy about discovering that
it no longer worked and was in fact unfixable.  Upside is
that it wasn't hard to make the kind of change described
in a) above and the result actually came out simpler.

Here are some other suggestions which would be helpful.

b) look into this issue of require default constructabiliy
of types.  Generally, default constructability is not a
requirement of serializable types.  I suspect that this
came about by accident and I also suspect it would
be easy to fix.

c) look into the possibility of factoring out the MPI
part so that the archive can be tested independently
of the MPI facility.  For example, if there were an
mpibuf similar to filebuf, then the mpi_archive would
could be verified orthogonally to mpi.  The mpi_archive
would in fact become a "super_binary" archive -
which presumably be even faster than the current
binary one and might have applicability beyond mpi
itself.

All the other archives do the above so I don't think
these enhancements would be very difficult.  Benefits
would be:

a) make things more robust - independent of binary
archive.  binary archive is sometimes hard because
the types actually used are sometime hidden behind
typedefs so it's hard to see what's going on.

b) make things more easily testable on all platforms.

c) make mpi_archive useful for things (which of course
I can't forsee) beyond just mpi.

I'm focused on getting past this current problem.  And
I think that implementing this suggestion is the only
practical way to do it.  I realize that this is a pain
but on the upside, it would make a huge improvement
to the mpi_archive at quite a small investment of
effort.

Robert Ramey