Announcement

Collapse
No announcement yet.

Qt 6.0 Officially Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by lowflyer View Post

    For the "completely headless applications", yes, this is absolutely possible. But the otherwise quite well done documentation is seriously lacking in this area.

    Well, the KISS applies in all other cases:
    databases API This is the only area where I see some value in having a Qt API. But as soon as you do something other than "Tables", use the respective databases' API directly which already is cross-platform
    threads use `std::threads` which is wherever your compiler is
    synchronisation use `boost::interprocess` if you are on C++ or the synchronization library of your language.
    sockets use the sockets directly. No other part of software has been that much cross-platform as the sockets.
    Dbus Dbus is mostly linux-only and currently under life support there. What's the point in being cross-platform here?
    XML Why on earth use Qt::XML? It's slow, it's buggy and it wont be fixed. Use any of the other available cross-platform libraries: tinyxml, pugixml, xerces etc.
    The idea is to use single db API regardless backend, to hide connection string differences etc. There is ODBC that does it but I don't know cross platform implementation of it (didn't check).
    Argument is: why would you additionally use boost if you already use Qt. Also, Qt was first, so your argument applies to boost rather.
    As for threads, C++ only "recently" has them in standard library while Qt predates all of it.
    Sockets are also bad example, as far as I remember you still need to do https://docs.microsoft.com/en-us/win...ock-wsastartup in your Windows code before you can use POSIX socket I/O functions.
    Last edited by reavertm; 09 December 2020, 08:25 AM.

    Comment


    • #22
      Originally posted by reavertm View Post

      The idea is to use single db API regardless backend, to hide connection string differences etc. There is ODBC that does it but I don't know cross platform implementation of it (didn't check).
      Argument is: why would you additionally use boost if you already use Qt. Also, Qt was first, so your argument applies to boost rather.
      As for threads, C++ only "recently" has them in standard library while Qt predates all of it.
      Sockets are also bad example, as far as I remember you still need to do https://docs.microsoft.com/en-us/win...ock-wsastartup in your Windows code before you can use POSIX socket I/O functions.
      reavertm, I think you put the cart before the horse.

      What you say is absolutely correct if you are in the position of "I have Qt, what else do I need". But the original post from Hibbelharry was about "why are these things in a GUI toolkit?". There is a lot of stuff that should not be in Qt. That would make it easier for them to maintain as well as the upgrade to 6.0.

      ODBC flies only on windows and there it has a different purpose.

      Counter argument: Why do you not use boost if you already use C++? Qt started when C++ was lacking many things. But we are past that. These missing bits were in boost since decades and are in the standard now. Qt missed the boat by not looking at boost. Instead they decided to self-knit what they deemed missing.

      Same with threads. boost::thread is available since 2001. QThread was introduced in 2005 (Qt 4). Earlier versions of Qt relied on pthread (which is another cross-platform standard). Not looking at boost::thread was again a mistake. It could have prevented them from inventing a difficult to handle API which required several re-writes and some help from outside.

      The socket example is not as bad as you think. Unix socket code works verbatim on windows. The windows-specific startup- and shutdown functions are easy to hide. Trade this against a dependency to Qt::Network. I would not study sockets by the microsoft documents. Beej's Guide to Netowrk Programming is a far better (and simpler).

      Comment

      Working...
      X