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.
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.
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.
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.
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?
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.