Adding a virtual function causes strange result...
-
@SPlatten said in Adding a virtual function causes strange result...:
it was resolved with the suggested qobject_cast.
Since your class is derived from QObject you can also use qobject_cast. Please learn the basics.
@Christian-Ehrlicher , I find your additions very insulting, I’ve been coding professionally since 1986.
-
@Christian-Ehrlicher , I find your additions very insulting, I’ve been coding professionally since 1986.
@SPlatten
I'm not sure what part of your code you think is implicated. I see:1 QListData::size() const 2 QList<std::pair<QString, QString>>::length() const
and that is failing (according to your "the execution stops in qlist.h on line 115") on trying to get the length of the
QList
. InvalidQList
at that point? That is what I see? -
@Christian-Ehrlicher , I find your additions very insulting, I’ve been coding professionally since 1986.
@SPlatten said in Adding a virtual function causes strange result...:
I’ve been coding professionally since 1986.
But not with c++ (at least I hope so) - when I want to learn a new language I normally start to learn the basics. But you ignore those basics in nearly every 'problem' you have and then wonder why people complain about the lack of the basics.
-
@SPlatten said in Adding a virtual function causes strange result...:
I’ve been coding professionally since 1986.
But not with c++ (at least I hope so) - when I want to learn a new language I normally start to learn the basics. But you ignore those basics in nearly every 'problem' you have and then wonder why people complain about the lack of the basics.
@Christian-Ehrlicher that’s a huge assumption on your part.
-
@SPlatten your stack trace actually points to your
clsXMLnode
class.
clsXMLnode::strGetAttribute@J-Hilk said in Adding a virtual function causes strange result...:
@SPlatten your stack trace actually points to your clsXMLnode class.
clsXMLnode::strGetAttributeIf he
reinterpret_cast
s it's going to point to that class and method since that's what to "reinterpret" means.@SPlatten said in Adding a virtual function causes strange result...:
I've replaced reinterpret_cast with dynamic_cast, same result.
You shouldn't use
reinterpret_cast
to begin with, as it's rather apparent you don't understand the implications of it; specifically to polymorphic calls and multiple inheritance. So while @Christian-Ehrlicher may seem brusque, you should do yourself a favor and listen to the advice.As for the issue at hand, you have called
strGetAttribute
on an invalid object, I'm reasonably certain. The reasons may vary, andreinterpret_cast
ing incompatible types is one. Dangling pointers and uninitialized memory are other candidates. You need to sift through the debugger to find it. Out of curiosity where doesclsQtLayout::addButton
callclsXMLnode::strGetAttribute
and where doesclsXMLnode::setWidget
callclsQtLayout::addButton
- provide the relevant code around the calls. -
@J-Hilk said in Adding a virtual function causes strange result...:
@SPlatten your stack trace actually points to your clsXMLnode class.
clsXMLnode::strGetAttributeIf he
reinterpret_cast
s it's going to point to that class and method since that's what to "reinterpret" means.@SPlatten said in Adding a virtual function causes strange result...:
I've replaced reinterpret_cast with dynamic_cast, same result.
You shouldn't use
reinterpret_cast
to begin with, as it's rather apparent you don't understand the implications of it; specifically to polymorphic calls and multiple inheritance. So while @Christian-Ehrlicher may seem brusque, you should do yourself a favor and listen to the advice.As for the issue at hand, you have called
strGetAttribute
on an invalid object, I'm reasonably certain. The reasons may vary, andreinterpret_cast
ing incompatible types is one. Dangling pointers and uninitialized memory are other candidates. You need to sift through the debugger to find it. Out of curiosity where doesclsQtLayout::addButton
callclsXMLnode::strGetAttribute
and where doesclsXMLnode::setWidget
callclsQtLayout::addButton
- provide the relevant code around the calls.@kshegunov , using the debugger I have a break point on the last if condition below:
clsXMLinterface* pobjInterface(reinterpret_cast<clsXMLinterface*>(pobjButton)); clsXMLnode* pobjNode(nullptr); if ( pobjInterface != nullptr ) { pobjNode = pobjInterface->pobjGetNode(); } if ( pobjNode == nullptr ) { return; }
pobjButton is a pointer to an instance of my derived class clsQtRadioButton:
class clsQtRadioButton : public QRadioButton, public clsXMLinterface { Q_OBJECT
pobjNode is returned as not null, pobjGetNode:
clsXMLnode* pobjGetNode() { return mpobjNode; }
I can see in the debugger the pobjInterface looks ok and mpobjNode is correct as I have assigned a human readable description to it:
However pobjNode doesn't appear to be correct:
And then trying to call strGetAttribute fails and causes the problem, but its because pobjNode isn't correct, why ?
If I change the code to:clsQtRadioButton* pobjRadioBtn(qobject_cast<clsQtRadioButton*>(pobjButton)); clsXMLnode* pobjNode(pobjRadioBtn->pobjGetNode());
This way pobjNode is valid and there is no problem, however I need a polymorphic way to access pobjGetNode because there can be lots of different types of object derived from the same base class and I need the functionality to work for all of them.
-
@kshegunov , using the debugger I have a break point on the last if condition below:
clsXMLinterface* pobjInterface(reinterpret_cast<clsXMLinterface*>(pobjButton)); clsXMLnode* pobjNode(nullptr); if ( pobjInterface != nullptr ) { pobjNode = pobjInterface->pobjGetNode(); } if ( pobjNode == nullptr ) { return; }
pobjButton is a pointer to an instance of my derived class clsQtRadioButton:
class clsQtRadioButton : public QRadioButton, public clsXMLinterface { Q_OBJECT
pobjNode is returned as not null, pobjGetNode:
clsXMLnode* pobjGetNode() { return mpobjNode; }
I can see in the debugger the pobjInterface looks ok and mpobjNode is correct as I have assigned a human readable description to it:
However pobjNode doesn't appear to be correct:
And then trying to call strGetAttribute fails and causes the problem, but its because pobjNode isn't correct, why ?
If I change the code to:clsQtRadioButton* pobjRadioBtn(qobject_cast<clsQtRadioButton*>(pobjButton)); clsXMLnode* pobjNode(pobjRadioBtn->pobjGetNode());
This way pobjNode is valid and there is no problem, however I need a polymorphic way to access pobjGetNode because there can be lots of different types of object derived from the same base class and I need the functionality to work for all of them.
@SPlatten said in Adding a virtual function causes strange result...:
why ?
We do not know whether and how you're initialising it...
"pobjNode is returned as not null" - doesn't mean it was initialised. You should initialise your pointers with nullptr before they are assigned proper pointers, else they can contain garbage.
-
@SPlatten said in Adding a virtual function causes strange result...:
why ?
We do not know whether and how you're initialising it...
"pobjNode is returned as not null" - doesn't mean it was initialised. You should initialise your pointers with nullptr before they are assigned proper pointers, else they can contain garbage.
@jsulm , here is the constructor for the class clsXMLinterface:
clsXMLinterface::clsXMLinterface(clsXMLnode* pobjNode) : mpobjNode(pobjNode) {
And clsQtRadioButton:
clsQtRadioButton::clsQtRadioButton(clsXMLnode* pobjNode, QString* pstrCSS , QWidget* pParent) : QRadioButton(pParent), clsXMLinterface(pobjNode) {
The formatting of this constructor is common to all instances. Widgets like instances of clsQtRadioButton are created by another call:
pobjWidget = qobject_cast<QWidget*>(clsCNT::pCreate(this, mstrName, strCSS, slstProperties, pobjParWidget));
clsCNT::pCreate:
QWidget* clsCNT::pCreate(clsXMLnode* pobjNode, const QString& crstrType ,QString& rstrCSS, QStringList& rslstProperties ,QWidget* pobjParent) { QWidget* pobjWidget(nullptr); if ( pobjNode != nullptr ) { if ( crstrType.compare(clsCNT::mscszButton) == 0 ) { pobjWidget = new clsQtPushBtn(pobjNode, &rstrCSS, pobjParent);
The above is just a sample, pobjNode is passed by pCreate as this.
-
@jsulm , here is the constructor for the class clsXMLinterface:
clsXMLinterface::clsXMLinterface(clsXMLnode* pobjNode) : mpobjNode(pobjNode) {
And clsQtRadioButton:
clsQtRadioButton::clsQtRadioButton(clsXMLnode* pobjNode, QString* pstrCSS , QWidget* pParent) : QRadioButton(pParent), clsXMLinterface(pobjNode) {
The formatting of this constructor is common to all instances. Widgets like instances of clsQtRadioButton are created by another call:
pobjWidget = qobject_cast<QWidget*>(clsCNT::pCreate(this, mstrName, strCSS, slstProperties, pobjParWidget));
clsCNT::pCreate:
QWidget* clsCNT::pCreate(clsXMLnode* pobjNode, const QString& crstrType ,QString& rstrCSS, QStringList& rslstProperties ,QWidget* pobjParent) { QWidget* pobjWidget(nullptr); if ( pobjNode != nullptr ) { if ( crstrType.compare(clsCNT::mscszButton) == 0 ) { pobjWidget = new clsQtPushBtn(pobjNode, &rstrCSS, pobjParent);
The above is just a sample, pobjNode is passed by pCreate as this.
This post is deleted!