bind.hpp needs a cwpro8 workaround
Pro8 is having trouble parsing these templates. Any ideas, Peter? template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); } template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); } --- ### mwcc Compiler: # In: C:\boost\boost\bind.hpp # From: named_params_test.cpp # ------------------------------ # 131: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) # Error: ^ # ')' expected ### mwcc Compiler: # 132: { # Error: ^ # declaration syntax error ### mwcc Compiler: # 133: return _mfi::dm<R, T>(*pm); # Error: ^^^^^^ # declaration syntax error ### mwcc Compiler: # 136: template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) # Error: ^^^^^ # ')' expected ### mwcc Compiler: # 137: { # Error: ^ # declaration syntax error # Too many errors printed, aborting program -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Pro8 is having trouble parsing these templates. Any ideas, Peter?
template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); }
template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); }
IIRC these support bind<R&>(&X::r, _1). Comment them out for cw8 and see if anything breaks. :-) (I hate these old compilers.)
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Pro8 is having trouble parsing these templates. Any ideas, Peter?
template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); }
template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); }
IIRC these support bind<R&>(&X::r, _1). Comment them out for cw8 and see if anything breaks. :-)
Nothing breaks. I just assumed you didn't ahve any tests for that case. And I had worked out this whole complicated patch. Waste of time! I assume you will apply the __MWERKS__ disablers?
(I hate these old compilers.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
IIRC these support bind<R&>(&X::r, _1). Comment them out for cw8 and see if anything breaks. :-)
Nothing breaks. I just assumed you didn't ahve any tests for that case. And I had worked out this whole complicated patch. Waste of time!
I assume you will apply the __MWERKS__ disablers?
Please apply them yourself, as you are the one with cwpro8 (and 9). I'm reluctant to apply patches when I can't test them, no matter how trivial. :-)
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
IIRC these support bind<R&>(&X::r, _1). Comment them out for cw8 and see if anything breaks. :-)
Nothing breaks. I just assumed you didn't ahve any tests for that case. And I had worked out this whole complicated patch. Waste of time!
I assume you will apply the __MWERKS__ disablers?
Please apply them yourself, as you are the one with cwpro8 (and 9). I'm reluctant to apply patches when I can't test them, no matter how trivial. :-)
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? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
IIRC these support bind<R&>(&X::r, _1). Comment them out for cw8 and see if anything breaks. :-)
Nothing breaks. I just assumed you didn't ahve any tests for that case. And I had worked out this whole complicated patch. Waste of time!
I assume you will apply the __MWERKS__ disablers?
Please apply them yourself, as you are the one with cwpro8 (and 9). I'm reluctant to apply patches when I can't test them, no matter how trivial. :-)
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), so there isn't much harm if we disable it for CW8. But we shouldn't disable it for CW9+ if there's no need. FWIW, my evaluation license for CW9.2 expired, too. ;-)
"Peter Dimov" <pdimov@mmltd.net> 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.
so there isn't much harm if we disable it for CW8. But we shouldn't disable it for CW9+ if there's no need. FWIW, my evaluation license for CW9.2 expired, too. ;-)
I'm waiting for MWerks to send me a regular copy of pro9, which I had to ask for explicitly. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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.
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" ATM.
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. :-)
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> 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" ATM.
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
"Peter Dimov" <pdimov@mmltd.net> writes:
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" ATM.
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
Aside from other issues, it sounds like you're telling me to do two different things here (just ifdef it out vs. apply your patch anyway). Please clarify. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Aside from other issues, it sounds like you're telling me to do two different things here (just ifdef it out vs. apply your patch anyway). Please clarify.
Update. bind< R& > doesn't work on MWCW (and MSVC 6.0/7.0) regardless of whether your patch is applied, because of the BOOST_WORKAROUNDs in mem_fn.hpp:298. Making it work across the board is a bit more effort than just patching unwrap(). Let's leave it unsupported.
"Peter Dimov" <pdimov@mmltd.net> 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),
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. I wouldn't want to vouch for it without some tests, though. Could you please write me some? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (2)
-
David Abrahams -
Peter Dimov