It is somehow reasonable to use QSharedPointer here. Most of the time it is not a good idea to use raw pointers (in modern C++). Someone has to manage the memory. Most of the time it will just work in Qt because most of the time Qt objects have a parent which will handle deletion of children when destroyed. If those pointers only live because they are inside a container, the container should use a smart pointer (I'd prefer std::shared_ptr over QSharedPointer, but that's a different topic).

There is an easy solution to the problem of connecting when using a shared pointer inside the map. connect() expects a raw pointer. For a smart pointer you get its raw pointer by calling get, i.e. objectsList[obj1].get(). This is the whole trick here.

@Linhares said in [SOLVED] Signals and slots as parameters:

addConnection("object1", "signal1", "object2", "slot1");

This approach will not work immediately. Once you get your connect() to compile it will tell you at runtime that the signal and slot could not be found. Certainly, you have to use the old connect syntax. The string needs to include the argument types, like "signal1(int)" or "slot1()". Or has that changed at some point?

Provide a minimal, compilable example where it crashes - everything else is just guessing.

@Dariusz said in QSharedPointer and... self reference?:

@SGaist Say I get 30-40k connections, it takes about 800ms to decrypt the packet, even when I run 50 threads that is 700 connections per thread that's 700ms per login packet etc etc.

Btw, do you have a 50 core machine? If you don't, then just don't.
Threads don't materialize performance out of thin air!

Simply run a few threads instead of wasting all the time in context switches.

I don't know how to prevent the qml from deleting the shared pointer.
So I return a new classs to qml, it works well. Hope anyone can tell me if it corrected.

} else if(role == modeRole) { if(deviceVariable.modeModelPtr.isNull()) return QVariant(); //return QVariant::fromValue(deviceVariable.modeModelPtr.data()); return QVariant::fromValue(new ModeModel(*deviceVariable.modeModelPtr)); } }; DeviceVariables { // .... QSharedPointer<ModeModel> modeModelPtr; } class ModeModel : public QAbstractListModel { public: //.... ModeModel(const ModeModel &other) : QAbstractListModel(other.parent()) { modeList = other.modeList; } private: QList<ModeData> modeList; };

I debug the ~ModeModel() and found the qml will auto delete the new ModeModel() which I provide in the cpp.

I created a SO question
and an issue

@Nishant-Sharma
Well if feel for it, you can add such info to the class yourself, maybe with extra debug information.
or simply use std::shared_ptr

Give it a day or two. I think other might have good idea regarding this :)

Awesome, thank you very much!

It's just a matter of calling:

connect(grabResult.data(), &QQuickItemGrabResult::ready, this, &MyClass::mySlot);

I haven't checked the current implementation but in any case it's a costly operation so using a shared object might also be a non-negligeable resource usage improvement.

Yes, Chris. That is right, once use shared pointer, never delete it.

This is the QSharedPointer.data() document in help. see content in []

do not delete the pointer returned by this function or pass it to another function that could delete it, [including creating QSharedPointer or QWeakPointer objects.]