Re: [boost] [serialization] Enhancing Archives with Archve Adaptors

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-11-27 00:04:33

Robert Ramey wrote:

>> I'd really appreciate it if you could answer this question from my
>> previous post:
>>
>>  2. Is this the promised simplification of the design we posted in
>>     http://lists.boost.org/Archives/boost/2005/11/97002.php?  If so,
>>     by what measure is your approach a simplification?
> 
> Honestly,  I don't remember what it was specfically in response to.

What?  You previously said (post dated Fri, 25 Nov 2005 14:38:41 -0800)
http://lists.boost.org/Archives/boost/2005/11/97201.php

|Shortly, I'll post some code that I believe addresses all your design
|goals in a much simpler and effective way.  That may be helpful
|in resolving this misunderstanding.

This was part of a long thread discussing the proposal in the link Dave
provided.

> It was intended to illustrate my view that the library can and should
> be extended without adding things to base classes, and finally
> that it simpler and more effective to do it this way.  The code
> attached implements all of the save_array functionality included
> in mattias system (actually more) in far fewer lines of code and with the
> benefits
> described in the posts.

Did you forget to include the attachment?  You cannot have intended the demo
you posted at the start of this thread, as that only implements a fraction
of Matthias' system.  Using either Matthias' original proposal, or Dave and
Matthias' revised proposal, an MPI archive that implements the save_array()
function via a call to MPI_Send() would be rather trivial to write (or at
least the actual MPI_Send() part would :-).  Your previous code offers no
such functionality, the only thing it does to speed array processing of
some 'bitwise_serializable' types.

If I got this wrong, then I apologise profusely for misunderstanding your
proposal, and I would be grateful if you could help me understand its
potential.  For example, by showing how such an MPI archive would be
written using the functionality of bitwise_oarchive_adaptor ?  For this
purpose, you could treat the MPI function as having the signature

template <typename T>
void MPI_Send(T* data, std::size_t count);

where T is any fundamental (non-pointer) type.

If instead you want to sketch any of the other proposals floating around in
the last few weeks, such as some other archive format like XDR or HDF, or
some other archive of your choice that demonstrates array functionality,
that would be fine too.  I am just interested in a sketch of the basic idea
here.

> 
>> And also, I'd appreciate it if you'd respond to the paragraph below.
>>
>>  I actually don't want to get into a discussion of which non-intrusive
>>  design is best.  The social and code interoperability dynamics of any
>>  non-intrusive design are the same, and that's really what I want to
>>  discuss.  Please let me know when you're ready to talk about that.
> 
> Sorry,  I don't even know what that means.

Maybe Dave is being a bit too subtle?  All I know is I feel an urge to run
away whenever I see "social" and "dynamics" in the same sentence ;)

Cheers,
Ian