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