setModelData crashes program

[VRonin]

If you want to use it in code that should still be present in release mode you can use Q_ASSUME

[JonB]

@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 so are 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 of qobject_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?

[VRonin]

Q_ASSUME in debug mode is like Q_ASSERT in release mode, if whatComboEditor 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

[JonB]

@VRonin
That wasn't quite the point, though. I was talking about writing the single-line statement (if Qt won't offer a qboject_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 suggested Q_ASSUME.

[VRonin]

• Q_ASSERT(statement);
  • Debug: if(!statement) triggerAnAssertion();
  • Release: ;
• Q_ASSUME(statement);
  • Debug: if(!statement) triggerAnAssertion();
  • Release: statement;

Is the difference clearer now?

[gabor53]

@VRonin
I added

 Q_ASSERT(whatComboEditor);

but it behaves the same.

[VRonin]

@VRonin said in setModelData crashes program:

Sounds like a model bug. What is fixModel?

[gabor53]

@VRonin

QSqlTableModel* fixModel = new QSqlTableModel(this);
  fixModel->setTable ("Items");
  fixModel->setEditStrategy (QSqlTableModel::OnRowChange);
  fixModel->setSort (2, Qt::DescendingOrder);

  fixModel->select ();

[JonB]

@VRonin

Is the difference clearer now?

Yep! :) Tx.

[gabor53]

@VRonin
Any way to go around the problem?
Would it be possible to just redraw the row in which the field was changed?