setModelData crashes program
-
That's not specific to Q_ASSERT, it's the same for the standard C++ assert. Always test the result of a function and not the function itself.
-
@VRonin said in setModelData crashes program:
If you want to use it in code that should still be present in release mode you can use
Q_ASSUME
Um,
I don't think soare you sure: http://doc.qt.io/qt-5/qtglobal.html#Q_ASSUME states it's a compile-time hint, and you get "undefined behaviour" if the condition is false. We need a runtime check of the return result ofqobject_cast<>
.EDIT: Unless the docs are misleading, and the true implementation is via https://git.merproject.org/faenil/qtbase/commit/3b0ed624351441a2d7be45cf9582fd36955ae860 , which uses
Q_ASSERT_X
? -
Q_ASSUME
in debug mode is likeQ_ASSERT
in release mode, ifwhatComboEditor
is null the program would crash anyway so you can't do much worse.The undefined behaviour comes from when you use the return value:
if(Q_ASSUME(false))
is undefined behaviour. if it just wraps an operation you do not check anyway,Q_ASSUME
does nothing to your compiled binary in release mode -
@VRonin
That wasn't quite the point, though. I was talking about writing the single-line statement (if Qt won't offer aqboject_assert_cast<>
):Q_ASSERT(whatComboEditor = qobject_cast<>)
versus
Q_ASSUME(whatComboEditor = qobject_cast<>)
The point being that it does the assignment. So we do need the expression to evaluate, just we don't need/care to do the "assertion" part of testing the result in release build. This would not work for
Q_ASSERT
as (I believe) it's a macro which produces nothing (no code at all) in release build. That was when you suggestedQ_ASSUME
.