From: David Abrahams (dave_at_[hidden])
Date: 2004-04-22 12:21:02
"Peter Dimov" <pdimov_at_[hidden]> writes:
> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>>> I don't have 9 since my beta license expired and a new one hasn't
>>>> arrived from MW yet. I could just turn those overloads off for all
>>>> __MWERKS__ if a conforming compiler shouldn't need them. Is that
>>>> what you had in mind?
>>> No, no. The overloads are required to support
>>> bind<int&>( &X::i, _1 )(x) = 5;
>>> but this is not a critical feature (which is why there are no tests
>>> for it),
>> I object. We should at least be trying to test everything.
> I agree in principle... but I'd say that we ought to test everything
> _supported_, and this isn't an "officially supported" feature yet, it's more
> a bonus/QoI thing, at least for now.
IMO code with no tests in the regression suite is just waiting to
become a bug, at which point it's not much of a bonus.
>> Aside from my objection, maybe you should accept my other patch in
>> that case, since it ought to function equivalently to the overloads
>> accepted by a conforming compiler.
> Too much of a change just to support one particular "bonus" feature on one
> particular broken compiler where nobody will likely attempt to use the
> feature. :-) Let's just #ifdef it out for cw8 and be done with it. At least
> for now. 'Cause I don't have the time to elevate bind< R& > to "supported"
Well, I still have to install pro9 and test the patch with that
before I can oblige, right?
>> I wouldn't want to vouch for it without some tests, though. Could you
>> please write me some?
> Sometime next week, maybe. But feel free to apply your patch anyway, as it
> only affects CW8, and it can't be worse than the overloads just being
> disabled, as is currently the case. :-)
Unless you checked in a change while I wasn't looking, they're not
disabled, but are still causing compilation errors on CW < 9.
-- Dave Abrahams Boost Consulting http://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