Reply With QuoteActually optional binary-compatible C++11 features are already there in Qt 4.8 beta (I'm referring to the last sentence in the article).
Phoronix News Bot
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
Junior Member
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).
Phoronix Member
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.
Senior Member
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
Senior Member
I hope that this isn't going to cause more bugs than lines of Windows 8 code
Senior Member
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.Originally Posted by ioannis
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.
Phoronix Member
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.
Senior Member
How do you know it is "sloppy"? Can you be more specific and point some actual examples, please.
Senior Member
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.
Senior Member
KDE4 was more about a re-write than about porting code. The only thing that will haunt it is bugs, obviously.
I thought KDE5 was about making stuff more modular. And when you restructure existing code, you might as well do your code porting then.KDE5 should be all about small cleanups, not porting to an entirely new codebase. Thankfully all the developers agree with this.
