Beman Dawes wrote:
On Mon, Nov 14, 2011 at 12:25 PM, Ruediger Berlich <ruediger.berlich@kit.edu> wrote:
Dear Robert, dear all.
from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ?
We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!).
My guess is that the C++ committee's Library Working Group (LWG) would be very interested in a proposal based on Boost Serialization.
I'm incredibly flattered that anyone would even suggest such a thing. However I've alway felt that this would be a bad idea. I have two sets of reasons for this. The first set pertains to serialization as implemented in my library. It wasn't really designed formally enough. I never really understood the concept of concepts until after I got everything (especially the documentation) done. This shows up in the library in lot's of ways - the large number of fixes I had to implement over the years. A series of ambiguities which show up from time to time. A few archive breaking changes which have caused much pain. But basically, the interface of the library hasn't been specified unambiguously enough to be basis of any sort of standard. The other reason is a lot more interesting. I made a large number of decisions about what "serialization" means. Amazingly to me - most people just accepted those decisions (but not all). Here are a few. a) the library doesn't define any i/o format. It is very closely tied to C++ and in general can't be used by other languages. For some people that makes a non-starter. See google protocol buffers. Peter Dimov raised the very point from the very beginning - and all I can say is that not everyone agrees that serialization is what I say it is. b) I implemented the concept of tracking so make archives more efficient and handle pointers. But this really conflicts with the usage of serialization for things like the MPI library. The MPI library uses the skeleton and doesn't track addresses. So this works great for using the same buffer to send and resend data blocks. This is very different than the archives which track the data. No one has ever noticed this. The serialization library interface it compatible with either one - ambguity again. c) I had the vision that it would non-intrusively handle abstract base class pointers. To me this concept was indispensable and crystal clear. Implementing such a thing turned to be very difficult. And just when you think you've done it, something else comes up. In particular, there's the issue of when part of the serialization is implemented in a DLL. It's very hard to make a huge program (where it is most useful) without violating ODR and introducing ambiguites in the program. Make the definition of serialization suffiently rigorus would be a big undertaking. Change would ripple through the implemention, and create a lot of work - and break current archives. Mostly it's the scale of work require which would disuade me. Actually, I'd personally prefer to spend more time making some archives to deal with editing. for example qt_i/oarchive where one would copy do something like window w; qt_oarchive oa(w); oa << my_data; ... edit the window elements qt_iarchive ia(w) ia >> my_data; // changes. Basically the serialization library is the truimph of development over design (from a description of the IBM selectric typewriter) A successful strategy perhaps - but not a good basis for a formal definition. Robert Ramey
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost