5 ms·

For sure, Qt is great even for CLI applications (if the dependency is not an issue).

fpoling 9y ago
We use QT for real-time data acquisition system. Works surprisingly nice. QT has good event loop abstraction and this is what C++ still lacks.
- 0xFFC 9y ago
  Awesome, I would love to read more about your systems. Do you have blog posts or something?
  - fpoling 9y ago
    In Norway it is a common knowledge that QT is a very reasonable choice for soft real-time. So I guess that is a reason people do not blog about it. One doesn't write about obvious things, does one?
gusmd 9y ago
Agreed! I use it at work for a CLI application that runs on an HPC environment. All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.
- geezerjay 9y ago
  Where's the added value of Qt's support for multithreading when compared with the C++ standard support for multithreading? IIRC, Qt introduces the irrelevant QReadWriteLock and that's it. In fact, the only upside of Qt's multithreaded support is that they were developed to serve Qt's very particular needs. Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.
  - WimLeers 9y ago
    QReadWriteLock predates C++11 by many years.
  - user5994461 9y ago
    >>> the C++ standard support for multithreading? 30 years in the making, still waiting for that thing to actually exist. How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.
  - gusmd 9y ago
    Last year I went through Anthony William's C++ Concurrency in Action to better understand the "new" threading library. No complaints. Actually, I've been using it in several components that are "pure C++" (i.e., no Qt, only STL). My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.

We use QT for real-time data acquisition system. Works surprisingly nice. QT has good event loop abstraction and this is what C++ still lacks.

0xFFC 9y ago
Awesome, I would love to read more about your systems. Do you have blog posts or something?
- fpoling 9y ago
  In Norway it is a common knowledge that QT is a very reasonable choice for soft real-time. So I guess that is a reason people do not blog about it. One doesn't write about obvious things, does one?

gusmd 9y ago

Agreed! I use it at work for a CLI application that runs on an HPC environment. All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.

geezerjay 9y ago
Where's the added value of Qt's support for multithreading when compared with the C++ standard support for multithreading? IIRC, Qt introduces the irrelevant QReadWriteLock and that's it. In fact, the only upside of Qt's multithreaded support is that they were developed to serve Qt's very particular needs. Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.
- WimLeers 9y ago
  QReadWriteLock predates C++11 by many years.
- user5994461 9y ago
  >>> the C++ standard support for multithreading? 30 years in the making, still waiting for that thing to actually exist. How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.
- gusmd 9y ago
  Last year I went through Anthony William's C++ Concurrency in Action to better understand the "new" threading library. No complaints. Actually, I've been using it in several components that are "pure C++" (i.e., no Qt, only STL). My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.