Announcement

Collapse
No announcement yet.

KDE Now Maintaining Their Own Set of Patches For Qt 5

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

  • Originally posted by ddriver View Post
    At this point I wonder how much kde might be willing to shell out on a viable framework alternative they could actually switch to.
    It's a lot less work, and cheaper for them to just fork Qt 5 and stay on that for a few years. Plus they get a stable base to build on.

    Comment


    • Originally posted by MadCatX View Post
      What do you consider standardized and how is it relevant for the discussion?
      The first public release is the only sensible baseline to compare the STL with Qt since Qt was never standardized. To argue that "Qt was first because the standard was ratified later" is hypocritical.

      Originally posted by MadCatX View Post
      Neither std::string, std:wstring nor QString store code points. std::string stores an array of bytes. std::wstring stores an array of wchar_ts, wchar_t is an implementation-defined integral type that may be as small as 8 bits (yes, really). QString stores an array of UTF-16 code units. std::string and std::wstring make no assumptions about the data they store. Since QString assumes its content to be a UTF-16 code unit sequence, it can implement Unicode-aware text handling consistently across multiple platforms. You still need to exercise caution when dealing with surrogate pairs in QString. However, AFAIK there is no string manipulation library that is considerably better in this regard.
      No. Don't let yourself be misled by the Qt documentation. The problem is just pushed 8 bits further down. To infer "Unicode-aware text handling consistently across multiple platforms" from this is simply wrong.
      Technically you are correct that wchar_t *may* be only 8 bits. But you'd be surprised what it *actually is* on your compiler. Behold the definition of wchar_t:
      wchar_t - Required to be large enough to represent any supported character code point (32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units)
      Or, check it for yourself with
      Code:
      std::cout << sizeof(wchar_t) << "\n";
      On Linux, std::wstring is considerably better than QString. On Windows, both are equally bad.

      Originally posted by MadCatX View Post
      When people talk about a local socket, I imagine that most people think of AF_UNIX kind of socket. Most APIs and SDKs use the name local socket to describe this device.
      Don't assume. At least one person didn't.

      Comment


      • By the way MadCatX . I'm not mad at you - despite my (often too-) edgy comments. Reading up documentation while replying to your posts thought me a whole lot. I honestly like tough technical discussions.

        Comment


        • Originally posted by lowflyer View Post
          The first public release is the only sensible baseline to compare the STL with Qt since Qt was never standardized. To argue that "Qt was first because the standard was ratified later" is hypocritical.
          Where are you going with this? STL simply was not an option when Qt was being developed so they wrote their own library functionally similar to STL. What does this have to do with standardization?

          Originally posted by lowflyer View Post
          No. Don't let yourself be misled by the Qt documentation. The problem is just pushed 8 bits further down. To infer "Unicode-aware text handling consistently across multiple platforms" from this is simply wrong.
          Technically you are correct that wchar_t *may* be only 8 bits. But you'd be surprised what it *actually is* on your compiler. Behold the definition of wchar_t:

          Or, check it for yourself with
          Code:
          std::cout << sizeof(wchar_t) << "\n";
          On Linux, std::wstring is considerably better than QString. On Windows, both are equally bad.
          You're still not getting it. It's all about guarantees. When you see a std::wstring, you cannot make any assumptions about the kind of data it contains. The fact that wchar_t is implementation-defined pretty much disqualifies it from any kind of multiplatform use. This is why C++11 introduced std::u16string and std::u32string. These at least guarantee the size of the character type. However, they still don't prescribe encoding.

          QString provides both guaranteed character size and prescribes UTF-16 encoding. This allowed Qt to have consistent string handling across all supported platforms. STL still doesn't do that even in 2021. It also enabled Qt to implement a lot of additional stuff like locale-aware comparisons, case conversions and other convenience functions for text manipulation. You cannot do that unless you have a well-defined string representation.

          Comment


          • Originally posted by MadCatX View Post
            Where are you going with this? STL simply was not an option when Qt was being developed so they wrote their own library functionally similar to STL. What does this have to do with standardization?
            Well, you chimed into this discussion with this statement:
            Originally posted by MadCatX
            Qt was developed before STL became a thing so they had do roll their own standards.
            Both, Qt and the STL were developed at around the same time. The trolls should have looked around to see how others address this common problem. Instead they ran just with the limited set of idioms they had acquired: Java. The notoriously most stupid decision in any software project is "to roll their own "standard"". They have done similar mistakes in other areas (null string != empty string, qmake, QBS). I find it upsetting that they seem to be ignorant about standards development. The standards and Qt have evolved since. But Qt has remained in their errors.

            Originally posted by MadCatX View Post
            You're still not getting it. It's all about guarantees. When you see a std::wstring, you cannot make any assumptions about the kind of data it contains. The fact that wchar_t is implementation-defined pretty much disqualifies it from any kind of multiplatform use. This is why C++11 introduced std::u16string and std::u32string. These at least guarantee the size of the character type. However, they still don't prescribe encoding.

            QString provides both guaranteed character size and prescribes UTF-16 encoding. This allowed Qt to have consistent string handling across all supported platforms. STL still doesn't do that even in 2021. It also enabled Qt to implement a lot of additional stuff like locale-aware comparisons, case conversions and other convenience functions for text manipulation. You cannot do that unless you have a well-defined string representation.
            I think I see your point. You put a high emphasis on multiplatform. And I should have pointed out std::u16string as the equivalent of QString.

            You don't seem to get what I try to point out: QString does not handle UTF-16. What it handles is UCS-2. The Qt documentation tries to get away with saying "each QChar corresponds to one UTF-16 code unit". This is only a 16 bit unsigned value - not the same as a "Code Point".

            If you compare the equivalent types, the guarantees of Qt are no better than the STL. Do not compare char with QChar. Furthermore, the STL provides wchar_t that does not exist on Qt. Strings from that type handle UTF correctly. You correctly point out that wchar_t is not 100% multiplatform, but with the STL it's easy to define a type that is: std::basic_string<u32char_t>. You'll struggle to get that with Qt.

            Let me show you where QString falls flat:
            Code:
            "😎 = \U0001F60E is B-)"
            This is a string that contains exactly 12 code points. Observe that Qt counts 14 characters which is not correct.

            See for yourself with the following code:
            Code:
            #include <iostream>
            #include <QString>
            #include <string>
            
            int main()
            {
                std::wstring const wstr{L"😎 = \U0001F60E is B-)"};
                QString qstr(QString::fromStdWString(wstr));
                std::cout << "wstring size:" << wstr.size() << " QString size:" << qstr.length() << "\n";
            }
            The inevitable consequence is that all the shiny "locale-aware comparisons, case conversions and other convenience functions for text manipulation" become unusable as soon as you have emojis or Asian languages in your QStrings. Well, you're still "multiplatform". But with that, Qt falls flat on all platforms. Note that microsoft compilers deliver the same wrong result: 14. And also note that std::wstring (on non-microsoft platforms) did handle that correctly since the dawn of time.

            Another point of annoyance: From Qt5 until somewhere in the middle of Qt5, the standard binary installation of Qt included a version of libicu. Initially this lead me to think that QString handles UTF correctly. But I had to learn the hard way that it does not despite including the resources to do it correctly.

            Comment


            • Originally posted by lowflyer View Post
              [...]
              That may be true, but I get the impression you're seeing UTF-32 as more useful than it actually is.This stuff is the reason that Rust chose UTF-8 as its internal string representation and people use the grapheme cluster iterator from unicode-segmentation a lot more than interacting directly with the char type. (See also the UTF-8 Everywhere manifesto.)

              Comment


              • lowflyer
                I don't know if you meant Microsoft compilers or compilers on Windows in general, but wstr.size() == 14 even with mingw.
                In your example the standard library outputs the right number, but not always.
                In this particular case Qt may be worse that the standard library, depending on the platform, but imho it's not enough to say that they should drop QString (and I'm not even taking into account the implicit sharing) and it's surely not enough to drop Qt as a developer.
                Also, there are graphemes represented with more than one code point, so the number of code points isn't always a meaningful information.

                PS: About the empty string being equal to nullptr I totally agree, it's bad design.

                ssokolow
                Qt has QTextBoundaryFinder to iterate over grapheme clusters: https://doc.qt.io/qt-5/qtextboundaryfinder.html

                Comment


                • ssokolow
                  Sorry for that impression. While I prefer UTF-8 for nearly anything, there are use cases for UTF-32. Thanks for the links. It was a really interesting read.

                  JackLilhammers
                  I'm not in a position to test every compiler on every platform. What I directly tested was:
                  • microsoft compiler on windows
                  • GCC on Linux
                  I also tested on godbolt.org
                  • clang
                  • gcc
                  • microsoft compilers on Wine x64 and x86
                  • icc
                  • webassembly
                  • arm, mips, power on gcc and clang
                  I found the results to be consistent with the definition on cppreference.com:
                  wchar_t - type for wide character representation. Required to be large enough to represent any supported character code point (32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units) It has the same size, signedness, and alignment as one of the integer types, but is a distinct type.
                  The mingw compiler apparently defines the flag "-fshort-wchar" which makes the wchar_t type 16 bit. I found also a discussion about "-no-fshort-wchar not working" that reasons microsoft compatibility.

                  I'm not hinting to "drop QString". But we have to be aware of its limitations and not blindly assume unicode support. Your link to QTextBoundaryFinder is really helpful. You may also notice the reason why the Copperspice guys did not copy QString, but created CsString

                  Comment


                  • lowflyer
                    I'm only stressing multiplatformity because that is Qt's biggest selling point. If you seek to target only one platform, Qt doesn't give that much better value than other toolkits (or a reasonable combination of multiple toolkits).

                    I still don't get your argument about STL vs. Qt library. When project A and B are developed at the same time, project B cannot really use project A if project A is not ready yet. I've already said it multiple times in this thread, there were only a few months between first STL public release and Qt public release. At that time nobody really knew how would STL pan out. It wasn't a standard, it wasn't well supported, it wasn't fast.

                    Take a look at how many platforms Qt1 supported when it was released. The list is actually longer because the commercial Qt1 included support for Win32. The list continued to grow until about Qt3. One of the reasons why Qt could achieve this level of multiplatformity was because it was very self-contained. The more you rely on 3rd-party code, the more likely you are to have to work around somebody else's bugs and STL is a pretty huge chunk of 3rd-party code to rely on. It also wasn't until C++11 when the STL containers started to provide clear benefits over Qt stuff.

                    I feel like you are trying to judge Qt's design decisions with today's optics. C++ devs have it embarrassingly easy today. There are basically three compilers, three (or maybe four) major platforms and three (maybe four) CPU architectures to support. Our tools are also much more advanced and polished then ever. The reality of the 90s was akin to a digital wild west. Do you think that your statement

                    Originally posted by lowflyer
                    std::wstring (on non-microsoft platforms) did handle that correctly since the dawn of time
                    would hold true if you had to use Watcom on WIn32, aCC on HP-UX and Metrowerks for Mac OS because that's what your customers wanted? (I myself had the distinct "pleasure" to use a compiler where the default enum size was configurable)

                    As for the neverending QString debate, let me make just a few last remarks:
                    - QString documentation is very clear about the fact that methods that take an index operate on code units and not codepoints nor graphemes.
                    - Qt has means to deal with "human" text units that take QString as the input. Again, since QString has a more strict definition than any STL string type, it is easier to write such functionality.

                    Comment


                    • Originally posted by MadCatX View Post
                      lowflyerwould hold true if you had to use Watcom on WIn32, aCC on HP-UX and Metrowerks for Mac OS because that's what your customers wanted? (I myself had the distinct "pleasure" to use a compiler where the default enum size was configurable)
                      Would that be Watcom or something else?

                      I noticed that Open Watcom retained that particular feature the last time I had time to work on my "InnoSetup/NSIS for DOS"-esque retro-computing hobby project where I'm trying to balance hackability (write it in C) and not crowding the actual content off a floppy disk.

                      (Fine-tuning the compiler flags for output size and replacing parts of the standard library with inline assembly to do BIOS FFI. just to position some text, graph.h added something like 35KiB to the base binary size (no thanks to Open Watcom not having true dead code elimination) when my goal is to fit a BASIC runtime, unzipper, installer-oriented standard library, and the user's install script and chosen theme into 15KiB... ideally 10KiB so I can beat the smallest non-.BAT commercial installer I found in my collection of floppies and DOS CDs.)
                      Last edited by ssokolow; 11 April 2021, 03:34 PM.

                      Comment

                      Working...
                      X