Subject: Re: [boost] [1.44] Beta progress?
From: Matthias Troyer (troyer_at_[hidden])
Date: 2010-07-25 16:44:46
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. 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
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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk