Re: [boost] [1.44] Beta progress?

Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-25 16:44:46

Hi Robert,

On 25 Jul 2010, at 10:28, Robert Ramey wrote:

> Matthias Troyer wrote:
>> O
>> 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.

This still does not solve the basic issue I'm trying to tell you. The problem we have now does not come about because of deriving from binary_archive. Even the common archive uses version_type, etc.. In order to implement an archive I will need to know the list of these primitive types that I have to support and their interface. Contrary to what you say the interface to those types has changed now. If you declare those types to be implementation details then I still cannot  implement an archive without making the "mistake: of relying on implementation details.

I realize that those might change occasionally, but then I want an updated list and a heads-up announcement of potentially breaking changes. 

> 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.

Sure, it can be fixed by a redesign of the MPI datatype creation. I just fear that such a redesign of a core part of the library a few days before a new release is not a good idea.

> 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.

Actually it seems you do not understand MPI well. Your proposal is not feasible for either of the archives we use: The "content" mechanism just sends from memory to memory, never going through any buffer. The packed archives use the MPI library to pack a buffer. Both require an MPI library. 

Matthias