apparently impossible qobject_cast is working!?

[FS Lover]

I have two questions please.
first, I dont understand how this cast from qt's examples (Tree Model Completer) works:

QAbstractItemModel *completionModel = completer->completionModel();
QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);

QAbstractItemModel *completionModel = completer->completionModel();
QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);

To copy to clipboard, switch view to plain text mode 

according to qt's class references, QAbstractItemModel doesnt inherit from QAbstractProxyModel.
although indeed completer->completionModel() is a QStandardItemModel, but it makes no deference (it inherits only from QAbstractItemModel that in turn doesnt inherit from QAbstractProxyModel).

complete code of that member function is this:

void MainWindow::highlight(const QModelIndex &index)
{
    QAbstractItemModel *completionModel = completer->completionModel();
    QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);
    if (!proxy)
        return;
    QModelIndex sourceIndex = proxy->mapToSource(index);
    treeView->selectionModel()->select(sourceIndex, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
    treeView->scrollTo(index);
}

void MainWindow::highlight(const QModelIndex &index)
{
    QAbstractItemModel *completionModel = completer->completionModel();
    QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);
    if (!proxy)
        return;
    QModelIndex sourceIndex = proxy->mapToSource(index);
    treeView->selectionModel()->select(sourceIndex, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
    treeView->scrollTo(index);
}

To copy to clipboard, switch view to plain text mode 

another question is why do we use a QAbstractProxyModel here?
this modified code works too:

void MainWindow::highlight(const QModelIndex &index)
{
/*     QAbstractItemModel *completionModel = completer->completionModel();
    QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);
    if (!proxy)
        return;
    QModelIndex sourceIndex = proxy->mapToSource(index); */
    treeView->selectionModel()->select(/* sourceIndex */ index, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
    treeView->scrollTo(index);
}

void MainWindow::highlight(const QModelIndex &index)
{
/*     QAbstractItemModel *completionModel = completer->completionModel();
    QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);
    if (!proxy)
        return;
    QModelIndex sourceIndex = proxy->mapToSource(index); */
    treeView->selectionModel()->select(/* sourceIndex */ index, QItemSelectionModel::ClearAndSelect | QItemSelectionModel::Rows);
    treeView->scrollTo(index);
}

To copy to clipboard, switch view to plain text mode 

qt 4.4.3

[caduel]

according to qt's class references, QAbstractItemModel doesnt inherit from QAbstractProxyModel.

for qobject_cast to work, QAbstractProxyModel needs to inherit QAbstractItemModel (in your case) - which is the case.

this modified code works too:

pure (bad) luck. the code is not correct.

[FS Lover]

for qobject_cast to work, QAbstractProxyModel needs to inherit QAbstractItemModel (in your case) - which is the case.

So can we say qobject_cast is a thing much more than other cast instructions?
To my eyes it seems that it somehow creates a new object or indeed extends an existing object.
(sorry if my questions are stupid and taking your time. I am new to qt and c++ both. I need to know these for pushing my c++ and qt view forward quickly.)
Are there any other cast instructions in standard c++ (specially) or qt that work similary?

pure (bad) luck. the code is not correct.

why? I wanted to know the reason.
can you explain for me please?
I have already said: another question is why do we use a QAbstractProxyModel here?
unfortunately qt documentation have not any documentation on this function at all.

[wysota]

So can we say qobject_cast is a thing much more than other cast instructions?

No, it's more than static_cast<>() but it is a direct equivalence of dynamic_cast<>(), only that it doesn't need compiler's help to do the cast.

To my eyes it seems that it somehow creates a new object or indeed extends an existing object.

It doesn't do anything like that. It just checks the actual inheritance tree using Qt's meta-object system and does the cast of the pointer if it is possible or returns null otherwise.

Are there any other cast instructions in standard c++ (specially) or qt that work similary?

Yes, as already said - dynamic_cast.

why? I wanted to know the reason.

Incidentally the position of the index in the proxy is same as the one in the base model. Pure luck, don't count on it. At best you will get wrong behaviour of the application, at worst it will crash.

I have already said: another question is why do we use a QAbstractProxyModel here?
unfortunately qt documentation have not any documentation on this function at all.

You should ask this question to a person who has written the code. I suspect QSortFilterProxyModel was applied on the view to provide sorting or filtering functionality.

[FS Lover]

Thank you guru. your texts opened my mind to a threshold required for discovering what I wanted to know.

please make your help complete and see if I am correct:

qt class reference says:
" QAbstractItemModel * QCompleter::completionModel () const
Returns the completion model. The completion model is a read-only list model that contains all the possible matches for the current completion prefix.
The completion model is auto-updated to reflect the current completions. "

extra explanation:
and QCompleter's class reference also says that QCompleter::highlighted() signal's argument is an index to the model returned by completionModel().
so this is the argument passed to our MainWindow::highlight function,
so we have to work with it and map it to the original model (QCompleter::model()) to highlight the item.

IMHO it is somewhat a lack of documentation that haven't mentioned explicitly that completionModel() indeed returns a QAbstractProxyModel (subclass).
but from the text and from some more complicated analysis that seems a little heavy for the very beginers like me, it can be implicitly argued.
Finally, success of the qobject_cast<QAbstractProxyModel *> makes we assured of which
QCompleter::completionModel() returns a QAbstractProxyModel (that in turn inherits from the QAbstractItemModel).

I was wondered why qobject_cast is always successful (not null).

but an unresolved thing!
I don't think that QAbstractProxyModel's inheritance from QAbstractItemModel can make a cast from QAbstractItemModel to QAbstractProxyModel successful.
a QAbstractItemModel doesn't have the function members and properties of a QAbstractProxyModel; it doesn't have such an interface!
that is the QAbstractItemModel that must inherit from the QAbstractProxyModel (which is not the case) for the cast to become successful, not the reverse.
are you sure about that yet?!
if yes, probably we can write some tests to see if such casts are possible.

[wysota]

IMHO it is somewhat a lack of documentation that haven't mentioned explicitly that completionModel() indeed returns a QAbstractProxyModel (subclass).

No, it's not lack of the documentation. You needn't know there is a proxy there. And you shouldn't try to access the proxy unless you know what you are doing (there might be no proxy there!)

I was wondered why qobject_cast is always successful (not null).

It's not, try this:

QAbstractItemModel *model = new QStringListModel;
QStandardItemModel *smodel = qobject_cast<QStandardItemModel*>(model);
Q_ASSERT(smodel!=0);

QAbstractItemModel *model = new QStringListModel;
QStandardItemModel *smodel = qobject_cast<QStandardItemModel*>(model);
Q_ASSERT(smodel!=0);

To copy to clipboard, switch view to plain text mode 

I don't think that QAbstractProxyModel's inheritance from QAbstractItemModel can make a cast from QAbstractItemModel to QAbstractProxyModel successful.
a QAbstractItemModel doesn't have the function members and properties of a QAbstractProxyModel; it doesn't have such an interface!

Pure magic, then

[FS Lover]

It's not, try this:

QAbstractItemModel *model = new QStringListModel;
QStandardItemModel *smodel = qobject_cast<QStandardItemModel*>(model);
Q_ASSERT(smodel!=0);

QAbstractItemModel *model = new QStringListModel;
QStandardItemModel *smodel = qobject_cast<QStandardItemModel*>(model);
Q_ASSERT(smodel!=0);

To copy to clipboard, switch view to plain text mode 

It's null buddy!
Indeed Q_ASSERT says its null when the prog is compiled in debug mode.
test>mingw32-make debug
...(and took very considerable time!!)
test>debug\test.exe
ASSERT: "smodel!=0" in file main.cpp, line 23

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

qt reference says:
Q_ASSERT() is useful for testing pre- and post-conditions during development. It does nothing if QT_NO_DEBUG was defined during compilation.

you can test for null other ways (a simple if or printing the pointer value), and you will see that its null.

[wysota]

It's null buddy!

So you see there are cases where qobject_cast doesn't return a valid pointer.

[FS Lover]

So you see there are cases where qobject_cast doesn't return a valid pointer.

such as when source object doesn't inherit from the cast's destination type.
you can test this for every qt class and all cases in the world, all will be null (impossible to dynamic cast successfully).

the only reason why what completer->completionModel() returns can be cast to a QAbstractProxyModel successfully is that indeed it inherits from or is a subclass of the QAbstractProxyModel.
If you have any doubts about that yet, again we can try to prove it (I think with the help of qt's meta object system I can prove it directly).

[FS Lover]

#include <QApplication>
#include <QErrorMessage>
 
#include <QCompleter>
#include <QAbstractProxyModel>
 
#include <QStringListModel>
#include <QStandardItemModel>
 
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QErrorMessage::qtHandler();
 
QCompleter c;
 
if(c.completionModel()->inherits("QAbstractProxyModel"))
qDebug("Yes, QCompleter's completionModel inherits QAbstractProxyModel");
else
qDebug("No, QCompleter's completionModel does NOT inherit QAbstractProxyModel");
 
QStringListModel slm;
 
if(slm.inherits("QStandardItemModel"))
qDebug("Yes, QStringListModel inherits QStandardItemModel");
else
qDebug("No, QStringListModel does NOT inherit QStandardItemModel");
 
return app.exec();
}

#include <QApplication>
#include <QErrorMessage>

#include <QCompleter>
#include <QAbstractProxyModel>

#include <QStringListModel>
#include <QStandardItemModel>

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QErrorMessage::qtHandler();

QCompleter c;

if(c.completionModel()->inherits("QAbstractProxyModel"))
qDebug("Yes, QCompleter's completionModel inherits QAbstractProxyModel");
else
qDebug("No, QCompleter's completionModel does NOT inherit QAbstractProxyModel");

QStringListModel slm;

if(slm.inherits("QStandardItemModel"))
qDebug("Yes, QStringListModel inherits QStandardItemModel");
else
qDebug("No, QStringListModel does NOT inherit QStandardItemModel");

return app.exec();
}

To copy to clipboard, switch view to plain text mode 

result:

Yes, QCompleter's completionModel inherits QAbstractProxyModel

No, QStringListModel does NOT inherit QStandardItemModel

[wysota]

such as when source object doesn't inherit from the cast's destination type.
you can test this for every qt class and all cases in the world, all will be null (impossible to dynamic cast successfully).

That's the point of qobject_cast... it does exactly the same thing dynamic_cast does, only that it doesn't need support from the compiler so it can (among other nice things) make a cast across library boundaries.

the only reason why what completer->completionModel() returns can be cast to a QAbstractProxyModel successfully is that indeed it inherits from or is a subclass of the QAbstractProxyModel.
If you have any doubts about that yet, again we can try to prove it (I think with the help of qt's meta object system I can prove it directly).

I know why the cast succeeds, you don't have to tell me. Either I can't understand the point you are trying to prove or there is nothing to prove and we're just chatting around about nothing.

If, by any chance, you meen that completionModel() should return a pointer to QAbstractProxyModel instead of QAbstractItemModel then the answer is: no, it shouldn't because it's not your business that it is a proxy model, you shouldn't try to touch it in any way; for you it is "some kind of" model and the behaviour can be changed between releases so you shouldn't expect the proxy to always be there.

[FS Lover]

I know why the cast succeeds, you don't have to tell me. Either I can't understand the point you are trying to prove or there is nothing to prove and we're just chatting around about nothing.

me:

first, I dont understand how this cast from qt's examples (Tree Model Completer) works:

QAbstractItemModel *completionModel = completer->completionModel();
QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);

QAbstractItemModel *completionModel = completer->completionModel();
QAbstractProxyModel *proxy = qobject_cast<QAbstractProxyModel *>(completionModel);

To copy to clipboard, switch view to plain text mode 

according to qt's class references, QAbstractItemModel doesnt inherit from QAbstractProxyModel.

you:

for qobject_cast to work, QAbstractProxyModel needs to inherit QAbstractItemModel (in your case) - which is the case.

such sentences reveal that you had misconceptions.
for a successful qobject_cast/dynamic_cast, source needs to inherit destination. reverse isn't true. we have no such necessary condition you mentioned. it has no relevance to the work of a dynamic cast.

[wysota]

for a successful qobject_cast/dynamic_cast, source needs to inherit destination. reverse isn't true.

For a successful qobject/dynamic cast an object being casted has to be an instance of the class you are trying to cast it to or its subclass. Period. This is a precise definition with no field for misinterpretation.

QAbstractProxyModel inherits QAbstractItemModel so you can cast an instance of the proxy model from an QAbstractItemModel pointer to QAbstractProxyModel pointer. And I'm sure we both agree to that. And if we do then I have no idea what is the point you are trying to make in this thread.

Assuming you are wondering why some qobject_cast works there is a simple test you can do:

QObject *ptr = <assign the dubious pointer here>;
qDebug() << ptr->metaObject()->className();

QObject *ptr = <assign the dubious pointer here>;
qDebug() << ptr->metaObject()->className();

To copy to clipboard, switch view to plain text mode 

[FS Lover]

No, it's not lack of the documentation. You needn't know there is a proxy there.

some of that qt's own example's functionality relies on knowing there is a proxy there and it makes use of it directly.
And its a common and standard usage.
so, why are you saying we don't need knowing that?!

[wysota]

so, why are you saying we don't need knowing that?!

Because you shouldn't touch the proxy as the completer relies on modifying it. If you modify the proxy, you will break functionality of the completer. That's why you get a pointer to the interface of the actual class, that's a standard way of doing things in object oriented languages supporting polymorphism.

Bear in mind QAbstractProxyModel is also an interface - the class is abstract so the instance behind the proxy pointer is really a subclass of QAbstractProxyModel (QSortFilterProxyModel probably).

[FS Lover]

Because you shouldn't touch the proxy as the completer relies on modifying it.

I agree that we shouldn't modify it, but it's sufficiently clear that programmers need to use it directly (of course without modifying it or relying on stability it doesn't have, etc; these must be implemented in the code properly).
what you say is relevant to programming in general that I know already, you know, its abc that every real programmer should know; it is relatively easy to understand and documentations are full of such warnings and advises, since many tools can be misused similarly (specially in languages such as C and C++). but essential programmer's tools never are hidden in order that no one can misuse them!
so I think it is no reason for the documentation not telling that; obviously, we should be aware of the existence of a tool to make use of it.
documentation could add extra explanations and advise about any misuse of a tool, which is very ordinary and frequent in qt and any other such documentations.
mentioning implicit knowledge about that could be a better reasoning.

[wysota]

I agree that we shouldn't modify it, but it's sufficiently clear that programmers need to use it directly (of course without modifying it or relying on stability it doesn't have, etc; these must be implemented in the code properly).

"Need"? Can you show me a case where you would "need" to use the QAbstractProxyModel API of the completion model ?

what you say is relevant to programming in general that I know already, you know, its abc that every real programmer should know;

There are many things so trivial people forget to do because they are so trivial that everybody knows them so they don't think about them and miss them.

but essential programmer's tools never are hidden in order that no one can misuse them!

Of course they are. For instance the "private" sections of classes in C++ are examples of such case.

so I think it is no reason for the documentation not telling that; obviously, we should be aware of the existence of a tool to make use of it.

No. The case with the completion model is an exact case where you should not know there is a proxy hidden behind. And in the next release of Qt there might not be a proxy there but the API has to remain unchanged.

documentation could add extra explanations and advise about any misuse of a tool, which is very ordinary and frequent in qt and any other such documentations.
mentioning implicit knowledge about that could be a better reasoning.

It's documentation, not a copy of the source code. Take a look at the source code and nothing will be hidden from your eyes.

[FS Lover]

Can you show me a case where you would "need" to use the QAbstractProxyModel API of the completion model ?

<qt installation dir>/examples/tools/treemodelcompleter/mainwindow.cpp: highlight member function.

every time we need to map the highlighted completion item to the original model the completion is performed for,
we need to use the QAbstractProxyModel API of the completion model.

in this qt's own example we need to do so in order to highlight the user's choice of the completion in the original model.

Of course they are. For instance the "private" sections of classes in C++ are examples of such case.

it is access to them in the programming environment that is restricted, not the knowledge about the existence and function of them in the documentation.
at least for those that programmer can makes use of them (e.g. in subclassing).

[wysota]

<qt installation dir>/examples/tools/treemodelcompleter/mainwindow.cpp: highlight member function.

every time we need to map the highlighted completion item to the original model the completion is performed for,
we need to use the QAbstractProxyModel API of the completion model.

This is a special case and qobject_cast is here so that you can do the mapping properly. If at all, I would say the completer should return an index from a base model instead of its own internal one but I don't agree it should return a proxy model api.

in this qt's own example we need to do so in order to highlight the user's choice of the completion in the original model.

As you see the example works, so you don't need it.

it is access to them in the programming environment that is restricted, not the knowledge about the existence and function of them in the documentation.
at least for those that programmer can makes use of them (e.g. in subclassing).

No. It's still internal and you shouldn't care.

[FS Lover]

This is a special case and qobject_cast is here so that you can do the mapping properly.

for what reason do you think it is special?
furthermore, what do you mean from special? what difference does it make regarding such uses we need?
you wanted an example case and I showed you one clear, simple, standard, and completely official one.
I think its clear enough to everyone.
so you have the responsibility to prove any further claim you make here.

I would say the completer should return an index from a base model instead of its own internal one but I don't agree it should return a proxy model api.

base model may be any model that can be potentially complex, costly to process, harder to work with, etc.
but regarding auto completion's suggestions and user's choice among them, many times we need only simple features without any further/external dependencies,
so a simple and shortened model that contains only the relevant items is the best to work with. that is what completionModel gives to us (a simple list model).
but sometimes we need to map indexes of this simple and shortened model to the original model that we want to work with directly.
on the other hand, this tells us what is the set of completion suggestions. this is essential.
so qt's way is the most efficient method. its not improperly designed.

As you see the example works, so you don't need it.

maybe I don't understand your meaning clearly.
can you explain more?
clearly, some feature of the example will not work without that functionality.