[Development] Qt LTS & C++11 plans (CopperSpice)

[Milian Wolff]

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.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150703/ef3190e5/attachment.bin>