On Dec 9, 2006, at 5:43 PM, Beman Dawes wrote:

Dinkumware has made a copy of their TR1 test cases available to me, and I've been running then on the Boost CVS HEAD and reporting apparent failures to Boost library maintainers.

John Maddock ran into some type traits test cases where the apparent failure was due to an issue with the TR1 spec itself. John wrote:

...

This all raises the um, interesting question of whether we should slavishly follow the TR1 text, or try to correct defects, and/or be ahead of the curve as Boost traditionally has been.

My answer is "that depends."

If there is a problem with the TR1 specification, we should implement what we think is correct, and file a defect report with the C++ committee.

If we have figured out a better way to do something, we should go ahead and implement the better way, and file a defect report with the C++ committee so that the C++0x version of the library can take advantage of the improvement. Should the deviation from TR1 be under macro control? Is this just QOI left up to the implementer?

But otherwise, we should just follow TR1. The point of having a Technical Report is that implementers all follow the same script.

Comments? Opinions?

I think it would be counter productive for boost to implement a clearly flawed spec, whether that spec be a TR or even a standard. There are places in the C++98/03 spec which I just flat refused to slavishly follow in the CodeWarrior implementation because I knew these ways to be inferior (and I know some other implementations which followed this philosophy as well). As long as I was right, customers never complained. When I was wrong, customers did complain. Boost should look to its customers for the final spec, not to an internal or external document. When customers disagree, you have to find a way to please as many as you can. Without customers, libraries such as boost have no purpose whatsoever. When boost tr1 implementations differ from tr1 specs, and purposefully - for good customer-oriented reasons, boost members should complain to the committee (and I just drew a bulls-eye on my forehead ;-)). In the case of the type traits library, for those concerned I encourage you to peruse: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html These are my suggestions for what needs to be changed for the type traits library in C++0X. The paper isn't perfect, and has a couple of obvious type-o's. I'll be writing a revision. Please send me your comments, both positive and negative, so that I can incorporate them into the revision. The first paper failed in committee for lack of motivating statements for the changes. So for positive comments, including *why* you like the proposed change (i.e. motivation) would be a great help (and thanks in advance). If the type traits library is important to you, this is your chance to get your input into committee on an easy fast track (I'll do the grunt work). Though no guarantees of success are implied here. I have to fight with the committee just like the next guy. -Howard