Announcement

Collapse
No announcement yet.

Qt 5, KDE 5 To Be Written In C++11 (C++0x)?

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

  • Qt 5, KDE 5 To Be Written In C++11 (C++0x)?

    Phoronix: Qt 5, KDE 5 To Be Written In C++11 (C++0x)?

    C++11, the new C++ ISO standard that was approved last month and formerly was known as C++0x, has been called to be employed by Qt and KDE as quickly as possible...

    http://www.phoronix.com/vr.php?view=OTkyNw

  • #2
    Actually optional binary-compatible C++11 features are already there in Qt 4.8 beta (I'm referring to the last sentence in the article).

    Comment


    • #3
      slots and signals?

      Does anyone know if C++11 has the notion (or something similar) of 'slots' and 'signals' used by Qt? I was hopping that the new standard will add enough run-time features to incorporate all those extensions added by Qt.

      Comment


      • #4
        It doesn't include signals/slots, but if you read the second blog post linked in the article you will see that it allows a more efficient implementation of the new connect() API introduced in Qt 5.0

        Comment


        • #5
          I hope that this isn't going to cause more bugs than lines of Windows 8 code

          Comment


          • #6
            Originally posted by ioannis View Post
            Does anyone know if C++11 has the notion (or something similar) of 'slots' and 'signals' used by Qt? I was hopping that the new standard will add enough run-time features to incorporate all those extensions added by Qt.
            No, nor should it. C++ strives to offer mechanisms for building high-level features, rather than encoding some specific implementation of a high level feature into the language. Signals and slots as Qt implements them are but one way to implement such a feature, and I've yet to see any other event-based C++ framework (including just about every game engine) need a crazy preprocessor or language extension to implement simple delegated event receivers.

            Features C++ could add that MOC includes would be the metadata system (but only with extreme care to ensure flexibility and extensibility without sacrificing OS-level performance and space-efficiency needs). That's not likely to happen soon though as building such a metadata system is very difficult to do right. Qt's makes a lot of assumptions and compromises that are not acceptable to many other potential users of a metadata system.

            Comment


            • #7
              Good news if you ask me!

              Cx11 is a very good place to break from the past. However the move should be to a major release, 5.0 most likely would be the best place to do that. If that means slipping the schedule a year or two so be it.

              I know this may offend KDE fans but KDE has become sloppy. Porting to a new code base would allow for cleaning that up.

              Comment


              • #8
                Originally posted by wizard69 View Post
                I know this may offend KDE fans but KDE has become sloppy.
                How do you know it is "sloppy"? Can you be more specific and point some actual examples, please.

                Comment


                • #9
                  Originally posted by wizard69 View Post
                  I know this may offend KDE fans but KDE has become sloppy. Porting to a new code base would allow for cleaning that up.
                  Please no. That's exactly what KDE4 was about, and it took a long time to bring the code back up to speed.

                  KDE5 should be all about small cleanups, not porting to an entirely new codebase. Thankfully all the developers agree with this.

                  Comment


                  • #10
                    Originally posted by smitty3268 View Post
                    Please no. That's exactly what KDE4 was about, and it took a long time to bring the code back up to speed.
                    KDE4 was more about a re-write than about porting code. The only thing that will haunt it is bugs, obviously.

                    KDE5 should be all about small cleanups, not porting to an entirely new codebase. Thankfully all the developers agree with this.
                    I thought KDE5 was about making stuff more modular. And when you restructure existing code, you might as well do your code porting then.

                    Comment

                    Working...
                    X