Results 1 to 10 of 10

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

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,638

    Default 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. #2
    Join Date
    Mar 2010
    Location
    Poland
    Posts
    11

    Default

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

  3. #3
    Join Date
    Feb 2007
    Posts
    87

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

  4. #4
    Join Date
    Oct 2010
    Posts
    309

    Default

    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

  5. #5
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

  6. #6
    Join Date
    Nov 2007
    Posts
    1,024

    Default

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

  7. #7
    Join Date
    Sep 2009
    Posts
    318

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

  8. #8
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

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

  9. #9
    Join Date
    Oct 2008
    Posts
    3,102

    Default

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •