@RyanSolanki Please mark as solved if you are happy the issue is resolved. Also consider reading up further about Qt's memory management model (maybe it would make sense to pass a parent during the QSqlQueryModel's construction to avoid all that manual memory management or else perhaps smart pointers if there is no clear parent to assign ownership to). Furthermore, SGaist's point about passing a pointer to a function whose signature expects a const reference cannot be understated. If the function expects a pointer, give it a pointer. If it expects a const reference, give it an object created on the stack! https://doc.qt.io/qt-5/qsqlquerymodel.html#details The documentation is good; use it! It is unclear to me why you are using functions such as "clear" for the model. The setQuery() function already clears the model. Why mess around with new and delete several times when you can just pass in a new query to modify the existing model? Futhermore, why bother clear()-ing the model immediately before you delete it? The destructor is called during the delete, which itself frees up any resources, per the documentation. There are deeper problems of comprehension going on here!

So it seems that I had two issues. Firstly, my program was creating table of 500*500 doubles every time I create a object of the Matrix class, and the second one was that I forgotten to set N-1 into determinat calculator. result was that my program was looping into infinity and every single time creating that massive matrix. Thank you very much for your help.

99.9999% probability you are trying to use the object you just deleted. If you call deleteLater on an object you then have to recreate it (e.g. with new) before using it or trying to delete it again

@JonnyQB Hi You declare it like Punkte * punkten; Then some place else you must do punkten = new Punkte(); ( not in .h) Often the constructor is a good place.

@cesar93 so if your problem is solved, please mark this topic as SOLVED too. Thanks

@Thynome Hi, Well, you're stuck with C when working with the WinApi. It sucks, I know, but you need to transfer the context (the object) through a global variable. You can look here for some inspiration - WindowsCtrlDispatcher::instance is the context that's transferred to the VOID WINAPI ServiceMain(DWORD, LPTSTR *) function. I hope that helps. Kind regards.

@kshegunov Finally I figured out that the problem is the missing QSqlDatabase::removeDatabase (); after db.close(); Thank you for your help!!!

Hi, i was experiencing the same strange thing... i was using Qt headers and non Qt headers, and placing before the Qt headers seemed to have solved the problem.

@mbruel said: What do you think, still something to avoid? You do want to free your resources, while this is usually done in the destructor, that might not always be the case (for example QFile has open() and close() methods, and internal state that it tracks. For speed optimisation and avoiding signal/slots when possible, well I don't know... I'm new to async programming and still don't really see the point to use a signal/slot mechanism with direct connection instead of directly calling the function on the object. It might not optimize a lot but it should definitely avoid few functions calls and passing by the event queue. When you connect objects that live in the same thread, you don't have any event queue calls (it's a direct connection, and behaves exactly like you've invoked the function yourself). A reason why you might want to use signals and slots, instead of pure function calls is to decouple components, which is something you'd want for the most part. I'm wondering if the impressive results of the QT version are due to the C++ and use of native socket or more of the non blocking sockets. Probably both, although internally (at the OS level) the sockets are blocking, you just don't see it. Also linux sockets, at least to my experience, tend to perform better than their windows counterparts. I don't know why, they just seem to be faster.

You're welcome ! Since you have it working now, please update the thread title prepending [solved] so other forums users may know a solution has been found :)

Ok, I found my mistake, I was just dumb. I didn't initialize something properly but it looked like it was a bit random so I didnt get it first.