BOOST_WORKAROUND and gcc warnings
Is the proposal here: http://svn.boost.org/trac/boost/ticket/1130 a viable way of fixing the pesky gcc warnings from BOOST_WORKAROUND? This one keeps coming up, but we've never had a way of fixing it that didn't involve a disproportionate amount of work... John.
John Maddock:
Is the proposal here: http://svn.boost.org/trac/boost/ticket/1130 a viable way of fixing the pesky gcc warnings from BOOST_WORKAROUND?
It works for me.
Peter Dimov wrote:
John Maddock:
Is the proposal here: http://svn.boost.org/trac/boost/ticket/1130 a viable way of fixing the pesky gcc warnings from BOOST_WORKAROUND?
It works for me.
That was my first thought, however, on reflection it looks fragile: with this change BOOST_WORKAROUND when applied to an unknown pp-symbol will always silently return 0, which isn't what we want to have happen :-( What if we reverse the logic a little: # define BOOST_WORKAROUND(symbol, test) \ (0 == (BOOST_WORKAROUND_GUARD_ ## symbol) && \ (symbol != 0) && (1 % (( (symbol test) ) + 1))) Which (I hope!) has no change to current behaviour if BOOST_WORKAROUND_GUARD_ ## symbol is not defined. Then for common pp-symbols we add: #define BOOST_WORKAROUND_GUARD_BOOST_MSVC !defined(BOOST_MSVC) And hopefully the warnings get suppressed: at least in the common cases. John.
on Sat Aug 25 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
What if we reverse the logic a little:
# define BOOST_WORKAROUND(symbol, test) \ (0 == (BOOST_WORKAROUND_GUARD_ ## symbol) && \ (symbol != 0) && (1 % (( (symbol test) ) + 1)))
Which (I hope!) has no change to current behaviour if BOOST_WORKAROUND_GUARD_ ## symbol is not defined.
Then for common pp-symbols we add:
#define BOOST_WORKAROUND_GUARD_BOOST_MSVC !defined(BOOST_MSVC)
And hopefully the warnings get suppressed: at least in the common cases.
Looks good to me. In which non-error cases would it fail to suppress the warning? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Then for common pp-symbols we add:
#define BOOST_WORKAROUND_GUARD_BOOST_MSVC !defined(BOOST_MSVC)
And hopefully the warnings get suppressed: at least in the common cases.
Looks good to me. In which non-error cases would it fail to suppress the warning?
It wouldn't suppress the warning if you use BOOST_WORKAROUND with a macro name it doesn't know about: but it would at least still do the right thing (where as the original suggestion wouldn't have done so). That's the idea anyway, needs testing locally etc... I'll wait till the regression tests are back on line in any case before taking this any further. John.
on Sun Aug 26 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Then for common pp-symbols we add:
#define BOOST_WORKAROUND_GUARD_BOOST_MSVC !defined(BOOST_MSVC)
And hopefully the warnings get suppressed: at least in the common cases.
Looks good to me. In which non-error cases would it fail to suppress the warning?
It wouldn't suppress the warning if you use BOOST_WORKAROUND with a macro name it doesn't know about: but it would at least still do the right thing (where as the original suggestion wouldn't have done so). That's the idea anyway, needs testing locally etc... I'll wait till the regression tests are back on line in any case before taking this any further.
I think that's the best we can hope for. Good job, everyone! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
participants (3)
-
David Abrahams -
John Maddock -
Peter Dimov