Opened 10 years ago
Closed 7 years ago
#8120 closed Bugs (fixed)
DONT_USE_HAS_NEW_OPERATOR warning with MSVC and Intel compiler
Reported by: | Owned by: | Robert Ramey | |
---|---|---|---|
Milestone: | To Be Determined | Component: | serialization |
Version: | Boost 1.59.0 | Severity: | Problem |
Keywords: | Cc: |
Description
I get the following warning relating to the DONT_USE_HAS_NEW_OPERATOR macro:
boost/archive/detail/iserializer.hpp(69): warning #3199: "defined" is always false in a macro expansion in Microsoft mode
I can reproduce this warning when using Intel Compiler 13.1 with VS2010. Previous versions of Intel compiler did not emit this warning.
However the warning appears to be correct as use of defined in a macro expansion is undefined by the standard. I also confirmed with a few tests that MSVC always evaluates such macros to false.
The solution I am using to fix this warning is to is replace all the uses of defined in the DONT_USE_HAS_NEW_OPERATOR macro with a comparison to 0. For example instead of
defined(__BORLANDC__)
use
__BORLANDC__ != 0
Change History (9)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
defined(...) only works at the top level inside #ifdefs. "If the token defined is generated as a result of this replacement process ... the behavior is undefined" (C++11 16.2) However, using XXX != 0 will also generate warnings. I believe that BOOST_WORKAROUND is safe to use.
comment:3 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I've removed this macro so I think this is no longer an issue
comment:4 by , 7 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | Boost 1.49.0 → Boost 1.59.0 |
Hello
The issue is still there with boost 1.59 In line 60 of boost\archive\detail\iserializer.hpp there is still the code:
#define DONT_USE_HAS_NEW_OPERATOR ( \ BOOST_WORKAROUND(__IBMCPP__, < 1210) \ || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \ )
And the Intel Compiler 15.0 together with Visual Studio 2015 produces the warning: .\boost/archive/detail/iserializer.hpp(64): warning #3199: "defined" is always false in a macro expansion in Microsoft mode So from my point of view the "bug" has not been fixed and this thread does not contain a workaround for fixing it. That's why I reopened this ticket.
Best regards
comment:5 by , 7 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
This produces a warning for microsoft and intel in microsoft mode.
The warning is of no value and can be safely ignored. Eliminating this code break code for ibm and sunpro compilers. If ths really bugs you, you can submit a patch which eliminates the bogus warning without breaking code for other compilers.
comment:6 by , 7 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Hello
From my point of view it is still a bug. MSVC thinks this code is wrong or at least suspicious, that why it throws this warning. From the warning text and also from the context of this code, it is not clear to me if the preprocessor really does the right thing here.
Well, you said the warning can be ignored, because the preprocessor will do everything right. That's ok... so the warning it not an impediment for users, that do not treat warning as errors. However the code is still not correct for MSVC and should be fixed in any further release.
I clearly understand, that fixing the code might be risky and could not be done very fast. That's why I think you should give a low priority to it, but you should not forget it or just close your eyes and hope there will never be an error due to that.
Best regards
comment:7 by , 7 years ago
I'm trying the following instead. I can't test it, so you should. Let me know how this works
#ifndef BOOST_MSVC #define DONT_USE_HAS_NEW_OPERATOR ( \ BOOST_WORKAROUND(__IBMCPP__, < 1210) \ || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \ ) #else #define DONT_USE_HAS_NEW_OPERATOR 0 #endif
comment:8 by , 7 years ago
With this fix the warning is not there anymore. Tested with Intel 16.0 and MSVC2015 compiler.
Thanks :-)
comment:9 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Hmmm that might be a big issue. I believe that defined(..) is used through out the code since it was more robust than checking a value. It never occurred to me that it wasn't supported by the standard. Maybe we should file an report to the standard.
How many instances of "defined(...)" did you have to change?
Robert Ramey