David Abrahams wrote:
<snip entire quoted thread>
Edward Diener <eddielee@tropicsoft.com> writes:
as I think the Boost one is better than anything I could do and better than anything else I have ever seen using standard C++. I will be glad to work with Mr. Ramey on the writing up a proposal part, since I am a fairly good writer, but it is obviously up to him and not me whether he wants to propose the library to the committee.
Not really. If you really want this to happen, *you* should commit yourself to proposing it, and then invite Mr. Ramey to join you.
I disagree on this. It is clearly wrong, in my eyes, to propose any library to the C++ standard committee when that library is someone else's work.
Why do you think so?
I greatly respect Mr. Ramey for the work he has done and is doing to make the Boost serialization library as good as it is but I would never want to propose such a library for inclusion as a standard library unless the creator of the library wanted to promote it also. It is also unfair to put that creator in such a position of extra work which standardizing a library might entail.
If that's the only reason, it's easily dealt with. The creator of the library isn't obliged to do anything to enable standardization. It can be your effort entirely.
Let me try to understand this. Are you saying that you ( the proverbial 'you', not the personal 'you' ) would take a library that someone else had developed, even if it is admittedly in the public domain, and propose it as a standard library to the C++ committee, making whatever changes might be necessary to get it accepted ? I am asking this quite seriously and not facetiously because for my own Regular Expression Component Library I took an earlier version of Boost regex++, made some small additions and changes to it, and incorporated into my own non-templated library interface which I have made available freely. I felt justified in doing this not only because Boost tells me this is legally OK but also because John Maddock generally understood what I was doing, and was helpful to me. But I would never have thought that it was right proposing my own slightly altered version of just the regex++ part of it to the C++ standards committee if John Maddock hadn't proposed regex+++ himself ( and of course a much improved regex++ than what I had used ). It still seems clear to me that if a public domain library developer wanted to have his library accepted as part of the C++ standard, that is his prerogative, not someone else's, and that attitude is a personal one not a legal one. I also can anticipate problems having someone else propose the library, and I am not talking about anything having to do with the effort of understanding internally how the library works. The biggest problem centers around changes that might have to be made in the library to satisfy the C++ standards committee. Once those changes are made there are now two stewards to the library and two slightly different versions of that library. I do not think this is a good situation. One now gets into arguments about what is better, which direction new decisions and designs should take, and the rest of that rigamarole which means difficulties and arguments to no good end. In the current Boost model, a single developer creates a library and others are free to chime in with suggestions, discussion, and even bug fixes, but it is still the resposnibility of that developer to be the author of that library. I like that model and only in vary rare situations, like with you and Aleksey with MPL, is that model different. For these general reasons I see it as a distinct disadvantage for having someone propose a library which they themselves have not developed. If Mr. Ramey were to say to me, go ahead and propose the library to the C++ standards committee, it is your call to learn the library and make whatever changes might be necessary to have it accepted, I would do it. But I do not know him and he does not know me and I would not want to put him under any pressure regarding this. I still feel very strongly that serialization should be part of the C++ standard so that instead of having every C++ implementation invent their own individual methods of serializing data to and from some persistent store, as many RAD and semi-RAD environments now do, there would be one standard way of doing things in this area. Needless to say a standard C++ library for serialization would also admirably serve the purposes of data transport between systems where the language is C++ on both ends.