About "Object's pointers & Memory"
I also take an advise from a Pro in C++ & memory management.
His solution is implement a Factory Pattern to Create/Delete Object's pointers
(also free memory when an instance had no pointer to it.)
(I think I'll give it a try)
Switch the order of the construction of objects. When the parent's destructor runs it'll try to free its children, but since you've created it after the child (hence its destructor will be called first), it will try to delete a stack object.
@mrjj I believe you are correct. I found out that the problem is my use of Q_DECLARE_OPAQUE_POINTER. It apparently prevents the meta type from registering as being derived from a QObject, which makes sense since at that point there's no way for Qt to know what the class is.
I refactored my code so that MyClass_p is no longer private or forward declared, and it fixed the issue.
The Q_OBJECT macro can be put in public, protected or private section and it will do the same. It doesn't matter for moc but I highly recommend to always put it at the top of your class for the following reason:
Thanks, I know that. I wanted to have a method of my private object to be queued for later execution, because the ChildAdded event that I'm handling in an event filter is propagated before the child object is fully constructed. It appears that the gadgets have no such capability so I've implemented the functionality as a private slot, and it works okay. For anyone that might be interested, here's how:
class AGUI_API AgDial : public QStackedWidget
Q_PRIVATE_SLOT(d(), void scheduleChildAdd(QPointer<QObject>))
With the corresponding invocation in the event filter:
Sorry for the late reply. Yes, you've got the essence of it. Qt's containers (QList included) are pretty smart in respect to copying, they will not copy the actual data until you change it. They are implicitly shared. This is done so you can return and copy the container many times, but in actuality internally only a pointer is reassigned and reference counter updated. When you call a non-const function on that list, Qt checks the reference counter and if more than one object is attached to the data, then and only then the data is detached (copied). When you put your list in the QVariant it is stored by value (making a shallow copy), but QVariant will return a shallow copy as well (meaning the data will not be changed, only the internal pointer reassigned and reference counter incremented).
Now, for your particular case:
The first line of code works, because you don't modify the list, but take an element (which is a pointer) and modify the object the list is holding reference to. This doesn't cause the list data to be copied. The second line you have, doesn't work, because you're changing the list data (assigning a new value to a list's element), which causes the list data to be detached and in practice, you're operating on a completely different set of data.
Here is a reference if you're interested in the way QList and other containers manage their data, and what implicit sharing is.
I tried to investigate the error, and i found where it is coming from
its from this line
which is written before the connect() in the code
The two list types are unrelated so casting pointers to them is still not ok at all. To push the previous analogy - for compiler it's like casting int* to string*. You can of course use reinterpret_cast and the compiler will be happy to trust you, but that is in no way correct and will obviously explode in your face at runtime.
@sierdzio Indeed the back ticks are not mandatory, however it gives the forum engine a good hint of what is following
in the cheat sheet you can actually find:
Blocks of code are either fenced by lines with three back-ticks ```, or are indented with four spaces. I recommend only using the fenced code blocks -- they're easier and only they support syntax highlighting.
The question is what is the syntax highlighting now?
How are you deleting your objects? Are you using delete or deleteLater? Seems odd this is happening since any delete on an object will delete all it's children before itself. At least with Qt parenting. If object X isn't a true child of B then that would cause your issue.
I.e. if I have:
QLabel *label = new QLabel();
QLabel *child = new QLabel(label);
// label should delete child by before it fully deconstructs.
Also if you have real code or at the very least a backtrace I could help more.
@Chris-Kawa That's a valid point I hadn't considered. I'll just have to give this some more thought.
It seems like maybe the most "Qt-correct" design would be to override childEvent(QChildEvent* event) to take the pointer into the member object when a child is added to the parent object. This would then, at least, bypass the need to call "findChild" over and over again.
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.