From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2006-12-10 16:15:39
On Dec 9, 2006, at 5:43 PM, Beman Dawes wrote:
> Dinkumware has made a copy of their TR1 test cases available to me,
> 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
>> 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++
> If we have figured out a better way to do something, we should go
> 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
In the case of the type traits library, for those concerned I
encourage you to peruse:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk