On 1/2/2019 4:00 AM, Thiago Macieira wrote:
I understand you're working with 4.8. I don't care.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
That would by why there are hundreds, possibly thousands of companies
all supporting their own fork of Qt and even more moving away from Qt.
They choose to use Qt.
Takes them 1-4 years to get a product out the door which has a 10-20
year market life.
By then, Qt has abandon them. There are __many__ medical devices running
4.8 out in the real world saving lives today. We've had this discussion
before. Most likely he is working on a medical device as well since 4.8
seems to be the most popular in that world.
On Wed, 19 Dec 2018 02:11:25 Ramakanth Kesireddy wrote:
Yes QApplication destructor is invoked last..Does it makes sense to use
deleteLater() in the widget destructors instead of existing delete if it
could be cleaned up as part of qApp-quit()?
On Tue, 01 Jan 2019 09:08:44 Ramakanth Kesireddy
However, in the actual application, if we delete the custom widget and
QApplication instance, then it throws segmentation fault on qApp->quit().
If we destroy any QObject without parent, then there is no seg error on
qApp->quit().
Does this error occurs because of double destroy that we manually destroy
objects and later qt also tried to destroy them?
I get this list in digest form so any attachments get stripped which
means I cannot see the code. Don't have time to look at it right now
anyway. Finishing up a couple of things and packing the ride to head out
for another medical device project on Friday. Never enough time when
starting a new project.
Here is what I remember from using this exact same version on a medical
device project a few years ago.
1) Never delete an object derived from QObject. If you feel compelled by
some forced design issue, use deleteLater(). Parents didn't handle the
external death of their children very well.
http://doc.qt.io/archives/qt-4.8/qobject.html
----
QObjects organize themselves in object trees. When you create a QObject
with another object as parent, the object will automatically add itself
to the parent's children() list. The parent takes ownership of the
object; i.e., it will automatically delete its children in its destructor.
When an object is deleted, it emits a destroyed() signal. You can catch
this signal to avoid dangling references to QObjects.
----
I don't know for certain and don't care enough to dig into it again,
but, I believe someone stated at some point that when a parented QObject
was created some of the parents didn't connect the destroyed() signal to
a slot which would remove the child from their list. It's a vague memory
and might never have been anymore than someone's wishful thinking. I
don't care. It seemed to fit what we found and we worked around the
limitation.
2) Forget all assumptions about what one can do in threads and how to
create them.
Sometime close to 4.8 is when the great sea change happened with QThread
and thread creation. We were supposed to be moving our code to things
like shown in the first snippet here:
http://doc.qt.io/archives/qt-4.8/qthread.html
But the "Derive a class from QThread" was still littered around the
Internet.
http://doc.qt.io/archives/qt-4.8/thread-basics.html
* Derive a class fromQThread
<http://doc.qt.io/archives/qt-4.8/qthread.html>, reimplement
theQThread::run
<http://doc.qt.io/archives/qt-4.8/qthread.html#run>() method and
useQThread::start
<http://doc.qt.io/archives/qt-4.8/qthread.html#start>() to run it.
Most of us stumble(d) pretty hard with the "Derive a class from QThread"
path to threading. Some stumbled so hard they started to mix and match
Qt threading with third party platform specific threading. They are
still doing that today. I turned down a project in Loveland, CO just a
scant few weeks ago where this is happening today. They are trying to
"sprinkle" Qt into their existing code base, using all of their existing
serial comm, networking, threading libraries (some rolled themselves I
believe) and they wonder why they are having problems.
Designs which view Qt as a "pinch of salt for the soup" will always
yield catastrophes.
When it comes to threading, don't derive from QThread. If someone
believes the design has forced them into deriving from QThread, change
the design.
The other problem you will run into with threads is basically problem 1.
If you have communications going on, especially a streaming type
communication like serial or some flavors of networking, it's not
uncommon to have a little worker be thread gathering up the octates into
a dynamically allocated buffer of some kind. When a "full packet" as
determined by the protocol has been received it puts that into a queue
structure of some kind where another thread will get to it when it gets
to it. When that thread is done with it, the dynamic buffer is supposed
to be freed.
IF you are doing this in 4.8, make it a block of raw RAM, not a QObject
based thing you create in one thread and nuke in another. I seem to
remember std::string working okay, but, don't quote me. DO NOT try to
cheat, using a QString, QByteArray, etc. in the gather thread then using
data() or constData() to queue up for the chewing thread.
All I remember for now.
Thanks for asking the question. Been meaning to write that stuff down so
I don't forget even more. Fairly certain I will be working with 4.8
again in the future. That's quite possibly __the__ most popular version
in the world of embedded systems, especially embedded systems in the
medical field.
Sadly I cannot tell you "go here" and you will find all of the embedded
systems developers working with 4.8. They don't come here. The community
abandoned them long ago. Your company has to find another company
(preferably not a competitor) which is using and maintaining their own
version of 4.8 (lots of them out there) then establish a "mutual
support" relationship. No, I'm not going to finger past clients or make
such introductions. Some/many/most of the NDAs would classify that as a
breach, at least the ones I have.
I hope this has been some tiny bit of help. Now I have to get onto my work.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
