Am 24.11.2018 um 15:52 schrieb Edward Diener via Boost:
On 11/24/2018 7:55 AM, Daniela Engert via Boost wrote:
Am 23.11.2018 um 20:58 schrieb Emil Dotchevski via Boost:
unsigned f();
void g( int x ) { if( x < f() ) //warning C4018: '<': signed/unsigned mismatch { .... } }
The only problem that I can see here is the fact, that this is flagged as a warning rather than an error. I know, this is technically correct but you simply cannot compare values from different value domains without preconditions. Not stating the preconditions is an error. If you state them and assure that the actual values of both 'x' and 'f()' can be equally represented as 'int' oder 'unsigned' then and only then the comparison is correct and a explicit cast to either type is a valid one.
Errors should be when you are not following the C++ standard. If you think that comparing a signed number with an unsigned number is not following the C++ standard you should reread the C++ standard.
I've already acknowledged that this is not an error according to the C++ standard. Nonetheless is it an error in the mathematical sense that it *may* invert the meaning of 'operator<' because of the implicit conversion rules of C++.
I do not mind this particular warning at all and go out of my way to fix it, but it is not an error in the C++ standard.
Right. Situations like these must be acted on. Just letting these go "because it is correct by the standard" is inacceptable imho.
This is what bothers me most about the idea that all warnings must be addressed in Boost libraries.
In most cases, I simply turn off compiler warnings by a #pragma after I convinced myself that "everything is fine, nothing to see here, get along". The simple fact that someone has audited warnings, acted accordingly, and then documented this - may be by just suppressing them in the source code - is an indicator of due diligence.
Therefore while warnings should be heeded I do not think it is possible in practical use to fix all warnings for all compiler implementations without making code even more obfuscated and more confusing than it normally is. It is an ideal to fix all warnings but it is not a realistic goal in quite a number of situations.
True. And I think earlier versions of MSVC went way overboard spitting out warnings about totally reasonable and perfectly valid code. The versions up to vs2013 were just a pain in the a**, and I am happy to compile my code using latest vs2017 only these days which is much more sensical in this regard. (I can only speak about experiences with msvc, it's the only compiler that we can use). Nevertheless, I made Boost compile - at least in our codebase - on vs2013 without warnings at /W4 after following the procedure described above: audit and act upon. Ciao Dani