on Tue Feb 17 2009, Sohail Somani <sohail-AT-taggedtype.net> wrote:
David Abrahams wrote:
on Tue Feb 17 2009, Sohail Somani <sohail-AT-taggedtype.net> wrote:
rather than figuring out hacks for each compiler. Previous to my implementation, there was a nasty #include ordering dependency. That's what I fixed. You introduced a gigantic regression. Is that not important?
It would be if it were true. But after my changes, all the regression tests passed for compilers we were supporting. So how's that possible?
That is strange. I distinctly remember it not working for g++ 4 for a while.
I remember something like that too. However, IIRC, that problem was a simple case of stupid incorrect code on my part, that somehow happened to work on earlier compilers. That had nothing to do with relying on compiler implementation details. Yep: https://svn.boost.org/trac/boost/ticket/1711
Do you mean to distinguish between compilers Boost is supporting and compilers Boost tests on?
No I do not. It was passing on all the compilers we tested on and/or I could get my hands on.
If so I'm not sure how helpful that is. In this case, tests that passed before, no longer pass.
Please know exactly what you're saying before you make that claim for a third time. I was *exceedingly* careful in testing these changes. Before we can know that I introduced a regression, we need to consider the original state of the code I checked in (since changed), the exact compilers that were available, and those we were testing on. So, as far as I can tell, GCC-4.1.0 came out a few months before my checkin, and I don't even know that the problem was occurring until a later release of 4.1.x, since the bug report isn't specific. https://svn.boost.org/trac/boost/changeset/34106 http://www.gnu.org/software/gcc/releases.html And again, the issue there has nothing to do with relying on implementation-specific hacks, and it wasn't reported until two years later (by you, incidentally). -- Dave Abrahams BoostPro Computing http://www.boostpro.com