[boost] Re: TR2 and C++0x heads up

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
proposal ;-)

> 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. 

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
> developed.

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.
Good luck!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com