On Thursday, July 02, 2015 10:09:13 PM Ansel Sermersheim wrote: > On 7/2/15 2:23 PM, Milian Wolff wrote: > > On Thursday 02 July 2015 23:00:43 Bernhard wrote: > >> Unfortunately adding signals of the template’s type is exactly what I > >> would > >> have needed several times. In that case there is no clean solution. I > >> once > >> added QVariant based signals as a workaround but that was ridiculous. In > >> modern times having powerful C++ generic programming features it is a > >> shame > >> that QObject doesn’t support this. IMHO this is one of the features (like > >> C++11) that need to be introduced in Qt as fast as possible if it should > >> not appear old-fashioned soon. > > > > You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it > > even uses a lot of C++11 features internally. So what exactly do you mean > > by the above? > > Yes, you can use C++11 in your application. Our viewpoint is that Qt > developers should be able to use C++11 internally in the project. They > are slated to allow most of C++11 like decltype, rvalue references, and > lambdas in 2016. However, things like constexpr will still not be allowed.
What was your reasoning behind forking the archaic Qt 4 instead of a recent Qt 5 which already uses a ton of C++11? Esp. note how it does use constexpr when available for many value types, thanks to the hard work by Marc. Also, considering that you were not working on the internals of Qt (or did you?), I find your reasoning above highly amusing. Forking Qt just to use C+ +11 for its internal development won't give users of the framework any value (quite the contrary, as Thiago pointed out many times). Also, as it's a fork, it won't affect us Qt developers at all, as we will stick to the original. > More importantly, there are many features of C++11 you cannot use in > your application like smart pointers. Ok, you can use them, but you > cannot use them to interact with Qt. To a modern C++ programmer this > comes across as a significant limitation. The above statement is far to broad to leave it uncommented. First, and foremost, the only place where Qt does not play nicely with smart pointers are QObject-inherited classes. This is true, but at the same time not a big deal as its parent-child ownership model has proven itself over the past twenty years. I'm not saying it's better than smart pointers, just that it's not much different. And furthermore, Qt is so much more than QObject inherited classes, and your own types in an application are also only QObjects if really necessary. All of the rest you can put into smart pointers if you want to, and Qt even offers it own fair share of smart pointers that are being used internally and externally (i.e. for C++98 projects). Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
