From: David Abrahams (dave_at_[hidden])
Date: 2005-04-27 15:32:24
Edward Diener <eddielee_at_[hidden]> writes:
> Let me try to understand this. Are you saying that you ( the
> proverbial 'you', not the personal 'you' )
I don't know what you mean by the "proverbial you;" I can only answer
for the "personal me."
> 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 ?
Yep. Of course the original author would be duly credited for his or
her work. I'd certainly let the author know what I was doing, and if
she or he objected I would certainly try to understand the reasons for
the objection, and I might think twice about proceeding.
> 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 still don't know why it's clear to you, but perhaps it's just one of
those things that has to be taken on faith.
> 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.
That's good, because internals (apart from implementability) are not
all that relevant to standardization.
> 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.
I understand your worries, but these things usually work themselves
out. I don't want to suggest that your concerns are entirely
unfounded, but at the same time it's easier to worry than to begin a
> 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
How is it different there?
> For these general reasons I see it as a distinct disadvantage for
> having someone propose a library which they themselves have not
I guess you have to decide whether those risks are worse than the risk
that no serialization library would be standardized.
> 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.
That's very considerate. Really. But I doubt anyone whose library
has successfully been through a pair of failed/accepted Boost reviews is
going to be made very uncomfortable if you ask him to let you propose
his interface design for standardization.
> 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.
I guess you have to decide how to balance your various considerations.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk