You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
Why is QGISDEBUG defined but Q_ASSERTs are not evaluated? Shouldn't QGISDEBUG be undefined in that scenario anyway?
Just wondering if fixing the problem at another point would have a bigger effect, avoid having to fix things like this again in the future and avoid the useless extra call to find().
The reason will be displayed to describe this comment to others. Learn more.
Why is QGISDEBUG defined but Q_ASSERTs are not evaluated? Shouldn't QGISDEBUG be undefined in that scenario anyway?
I have no idea why the use of 'it' inside of the Q_ASSERT bool parameter isn't noticed by the compiler after expanding the macro. This is compiling with clang on Mac from inside Qt Creator 3.5.0, with -DQGISDEBUG=1, so the definition is there. Not sure how it would be undefined in this situation.
Just wondering if fixing the problem at another point would have a bigger effect, avoid having to fix things like this again in the future and avoid the useless extra call to find().
Not sure I understand what fix in another place would keep this warning from showing up. I think it is localized to the Q_ASSERT macro and its expansion (or lack thereof). Should expand to the following (which should contain the variable in the condition) after preprocessing (from /src/corelib/global/qglobal.h):
The reason will be displayed to describe this comment to others. Learn more.
@dakcarto is the warning produced for release builds or debug builds? For debug builds it would probably be good to have QT_NO_DEBUG unset and have the checks performed. Just a random guess, is that compiled with RelWithDebInfo and that's an effect of this?
Looks like someone (@nyalldawson ?) ran into this before and used the Q_UNUSED workaround as well, but apparently for a variable used within a QgsDebugMsg() call, which is a bit more odd, in that that macro is not expanding to a noop. Of the 77 uses of #ifdef QGISDEBUG there are no others that have a nested Q_ASSERT.
Suggestions on the best fix here? Just #include <cassert> and use assert(...) instead?
The reason will be displayed to describe this comment to others. Learn more.
Inclusion will just fix asserts in this file, no?
What about changing it to #ifndef QT_NO_DEBUG and
build with built type DEBUG
or
Make sure that RelWithDebInfo undefs QT_NO_DEBUG (or is having QT_NO_DEBUG defined the whole point of the RWDI configuration and there's some problem with this on mac)?
Make sure that RelWithDebInfo undefs QT_NO_DEBUG (or is having QT_NO_DEBUG defined the whole point of the RWDI configuration and there's some problem with this on mac)?
I think that is the point: just textual debug output, with no per-line testing.
8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is
QGISDEBUG
defined butQ_ASSERT
s are not evaluated? Shouldn'tQGISDEBUG
be undefined in that scenario anyway?Just wondering if fixing the problem at another point would have a bigger effect, avoid having to fix things like this again in the future and avoid the useless extra call to
find()
.8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea why the use of 'it' inside of the Q_ASSERT bool parameter isn't noticed by the compiler after expanding the macro. This is compiling with clang on Mac from inside Qt Creator 3.5.0, with
-DQGISDEBUG=1
, so the definition is there. Not sure how it would be undefined in this situation.Not sure I understand what fix in another place would keep this warning from showing up. I think it is localized to the Q_ASSERT macro and its expansion (or lack thereof). Should expand to the following (which should contain the variable in the condition) after preprocessing (from
/src/corelib/global/qglobal.h
):8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC the Q_ASSERT macro is like a noop when QT_NO_DEBUG is set (i.e. release).
I guess there's no way to avoid to put Q_UNUSED after the Q_ASSERT if the variable is unused out of the assert condition.
8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If so the check should be for QT_NO_DEBUG instead of QGSDEBUG?
8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dakcarto is the warning produced for release builds or debug builds? For debug builds it would probably be good to have QT_NO_DEBUG unset and have the checks performed. Just a random guess, is that compiled with RelWithDebInfo and that's an effect of this?
8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@m-kuhn wrote:
Bingo! That was exactly the issue, since I am doing RelWithDebInfo builds. So, in the
qgis2.11.0.cbp
file produced during configure, it definesLooks like someone (@nyalldawson ?) ran into this before and used the Q_UNUSED workaround as well, but apparently for a variable used within a
QgsDebugMsg()
call, which is a bit more odd, in that that macro is not expanding to a noop. Of the 77 uses of#ifdef QGISDEBUG
there are no others that have a nested Q_ASSERT.Suggestions on the best fix here? Just
#include <cassert>
and useassert(...)
instead?8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inclusion will just fix asserts in this file, no?
What about changing it to
#ifndef QT_NO_DEBUG
andor
8f04d22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Fixed' in 307806a.
I think that is the point: just textual debug output, with no per-line testing.