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

[charleyb123 .]

>
> <snip, shared pointers>
>

Bo Thorsen sayeth:

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

This.

Thank you, Bo.  We regularly see issues with "new-grads" that seem to think
that naked pointers should no longer exist, and all things should be
std::unique_ptr or std::shared_ptr.  OMFG.

My assertion is that Design is:

(1) What objects should exist.
(2) Who owns them.
(3) There is no "Number Three"

...and, we almost never have a good reason to use shared pointers.

For you to use this as a reason for forking Qt is a very bad indication.
>

I'm curious how much of the CopperSpice motivation is this, or other things
like signals-on-templates and removal of moc.  (I no longer need
signals-on-templates, but many years ago I thought I did.)

I must say, some of the CopperSpice decisions are very clever (heavy use of
preprocessor to generate unique IDs that would otherwise be handled by
moc).  I similarly thought the Woboq guys with their moc-removal approach
was quite clever, and these are two very different examples of a
"possible-future-direction-of-Qt" that I think is quite healthy for our
community to discuss.

I appreciate the CopperSpice guys talking about their decisions and
rationale on their design approach, and hope they will remain active in
these forums.

It's quite clear to me that some of the very dramatic moves occuring in
C++14/17, including possible modules, and some of the new TMP capabilities
open up options that we never previously could consider.

And, it seems that some of these patterns and directions remain somewhat
"unexplored" or otherwise represent "new territory" for consideration.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150703/8ada821d/attachment.html>