Den 03-07-2015 kl. 07:09 skrev Ansel Sermersheim: > > > 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. > > 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.
This answer is going to be one big IMHO. Anything that stops people from throwing shared pointers all over the code is A Good Thing. As someone once said: Shared pointers are a solution in search of a problem. Scoped pointers are fine, but shared pointers indicate a lack of handling of responsibility and ownership, which indicates bad design. For you to use this as a reason for forking Qt is a very bad indication. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development