[Development] Qt LTS & C++11 plans

[Knoll Lars]

Hi,

I’ve went through the plans that we now have for Qt 5.6 and think that we
need to slightly adjust our plans to deprecate certain compilers and move
over to C++11.

We are currently around 6 weeks away from the 5.6 feature freeze, and
currently the dev branch is still nicely compiling in C++98 mode, and we
still test all the older compilers (and platforms such as WEC7) in the CI
system. I do not see us gaining much from throwing this support now out a
couple of weeks before the feature freeze. On the opposite, I’m afraid it
would lead to us trying to rush some new code at the last minute and not
give us proper time to test before the freeze.

After discussing with a couple of different people, here’s the updated
proposal for 5.6 and onwards.

Qt 5.6:

* We make 5.6 a long term supported release
* We still support C++98 compilers in this release (for the last time),
i.e. We keep the 5.5 compiler baseline
* WEC7 will be still supported
* QNX 6.5 is not supported anymore
* Qt Quick1 and Qt WebKit are not part of the release (but we test that
the sources compile against 5.6)
* We keep Qt Script for this release, it’ll be gone in 5.7 as well

Qt 5.7:

* New compiler baseline with gcc 4.7 and VC++ 2012
* Enable and use the C++11 features supported by these compilers
unconditionally
* WEC7 not supported anymore, WEC2013 supported
* Probably remove support for older Android, Mac and Linux versions as
well (to be discussed)

This would mean that we’d simply remove the older compilers and platforms
from the dev branch of the CI system a few weeks later than originally
planned. From an R&D perspective it means we can start fully relying on
the new compiler baseline from the beginning of August (once we branched
5.6). So it’s a rather small delay from an R&D perspective, but it’ll give
us a broader baseline of supported platforms and compilers for our LTS
release. It’s basically what we wanted to do for 5.5, but couldn’t because
the CI system wasn’t yet in place.

Cheers,
Lars

[Thiago Macieira]

On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well
>
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

+1
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Giuseppe D'Angelo]

On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars
<***@theqtcompany.com> wrote:
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

Random thought: call it Qt 6? :-P

But the plan sounds nice to me.

Cheers,
--
Giuseppe D'Angelo

[Konstantin Ritt]

2015-06-23 20:47 GMT+04:00 Giuseppe D'Angelo <***@gmail.com>:

> On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars
> <***@theqtcompany.com> wrote:
> > Qt 5.7:
> >
> > * New compiler baseline with gcc 4.7 and VC++ 2012
> > * Enable and use the C++11 features supported by these compilers
> > unconditionally
> > * WEC7 not supported anymore, WEC2013 supported
> > * Probably remove support for older Android, Mac and Linux versions as
> > well (to be discussed)
>

Do we really need WEC7 support these days?

Regards,
Konstantin

[Knoll Lars]

On 23/06/15 20:56, "Konstantin Ritt" <***@gmail.com<mailto:***@gmail.com>> wrote:


2015-06-23 20:47 GMT+04:00 Giuseppe D'Angelo <***@gmail.com<mailto:***@gmail.com>>:
On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars
<***@theqtcompany.com<mailto:***@theqtcompany.com>> wrote:
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

Do we really need WEC7 support these days?

Yes, we need a solution where we can support it for at least 2 more years. It's easiest and most maintainable if that's simply done by making it part of Qt 5.6 LTS.

Cheers,
Lars

[Thiago Macieira]

On Tuesday 23 June 2015 18:47:47 Giuseppe D'Angelo wrote:
> Random thought: call it Qt 6? :-P

Let's not.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Marc Mutz]

On Tuesday 23 June 2015 22:01:27 Thiago Macieira wrote:
> On Tuesday 23 June 2015 18:47:47 Giuseppe D'Angelo wrote:
> > Random thought: call it Qt 6? :-P
>
> Let's not.

I agree. Qt 5 required full C++98 support, IMO, Qt 6 should require full C++11
support, maybe C++14, and that's still far, far away.

How wrong I was believing Herb Sutter @ GoingNative 2012 about MSVC picking up
the pace...

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Bo Thorsen]

Den 23-06-2015 kl. 12:17 skrev Knoll Lars:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well

To me this looks like the perfect plan. It's exactly what all customers
I have spoken to have been asking for as well.

With an LTS release that has almost all of the modules of the Qt 5
lifetime, I'd be fine with dropping the compilation requirements of
webkit and quick1 from 5.7.

IMO that's the benefit that an LTS support should give - to allow us to
completely drop support for old modules. This gives the option of
shifting resources from keeping f.e. webkit compiling with the latest
version to keeing it running with the LTS release.
Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu

[Kevin Kofler]

Bo Thorsen wrote:
> With an LTS release that has almost all of the modules of the Qt 5
> lifetime, I'd be fine with dropping the compilation requirements of
> webkit and quick1 from 5.7.
>
> IMO that's the benefit that an LTS support should give - to allow us to
> completely drop support for old modules. This gives the option of
> shifting resources from keeping f.e. webkit compiling with the latest
> version to keeing it running with the LTS release.

GNU/Linux distributions will require QtWebKit to keep compiling for a LONG
time to go.

In fact, it is already a big problem for us that it is being deprecated at
all. QtWebEngine is not an adequate replacement, neither for developers
(insufficient API), nor for packagers (bundling Chromium that itself bundles
dozens of libraries makes this a completely unacceptable package for at
least Fedora and Debian). But even if it were, applications are not going to
be ported to it overnight.

We cannot just ship the LTS Qt because some applications will definitely
require the latest Qt, and having 2 different Qt 5.x versions around is NOT
going to work. Unlike the average application developer, we have MANY
applications and libraries to care about, and they need to be able to work
together.

Kevin Kofler

[Thiago Macieira]

On Monday 29 June 2015 01:22:17 Kevin Kofler wrote:
> GNU/Linux distributions will require QtWebKit to keep compiling for a LONG
> time to go.

You'd do everyone a service and stop that soon, as shipping a web engine that
is not receiving security updates is a dangerous thing to do. Applications
that depend on it will need to be ported away from it or dropped from the
repository, unfortunately.

> In fact, it is already a big problem for us that it is being deprecated at
> all. QtWebEngine is not an adequate replacement, neither for developers
> (insufficient API), nor for packagers (bundling Chromium that itself bundles
> dozens of libraries makes this a completely unacceptable package for at
> least Fedora and Debian). But even if it were, applications are not going
> to be ported to it overnight.

Chromium devs are willing to talk about unbundling. Have you reached out to
them?

> We cannot just ship the LTS Qt because some applications will definitely
> require the latest Qt, and having 2 different Qt 5.x versions around is NOT
> going to work. Unlike the average application developer, we have MANY
> applications and libraries to care about, and they need to be able to work
> together.

Fortunately, you will be able to compile QtWebKit and QtScript 5.6 with some
future versions of Qt. As long as someone is testing then and supplying build
fixes, it should work.

QtQuick1 will stop working soon after 5.6 due to its immense use of Qt private
API.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Francesco Riosa]

Il 29/06/2015 02:02, Thiago Macieira ha scritto:

SNIP
>> In fact, it is already a big problem for us that it is being deprecated at
>> all. QtWebEngine is not an adequate replacement, neither for developers
>> (insufficient API), nor for packagers (bundling Chromium that itself bundles
>> dozens of libraries makes this a completely unacceptable package for at
>> least Fedora and Debian). But even if it were, applications are not going
>> to be ported to it overnight.
> Chromium devs are willing to talk about unbundling. Have you reached out to
> them?
>

sorry for the intrusion, about unbundling a good number of bundled
libraries can be unbundled, gentoo do this, search
"remove_bundled_libraries.py"
in the following ebuild (bash script)

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-45.0.2438.3.ebuild

most but not _all_ are libs are unbundled, maybe more hands on problem
could help reaching perfection ;)
good luck

SNIP

[Daniel Teske]

> * WEC7 not supported anymore, WEC2013 supported
So what is the time frame for dropping WEC2013? Because that's the time Qt
will be stuck with MSVC2012.

daniel

[Knoll Lars]

On 25/06/15 11:43, "Teske Daniel" <***@theqtcompany.com> wrote:

>> * WEC7 not supported anymore, WEC2013 supported
>So what is the time frame for dropping WEC2013? Because that's the time
>Qt
>will be stuck with MSVC2012.

WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.

Cheers,
Lars

[Daniel Teske]

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote:
> On 25/06/15 11:43, "Teske Daniel" <***@theqtcompany.com> wrote:
>
>
> >> * WEC7 not supported anymore, WEC2013 supported
> >
> >So what is the time frame for dropping WEC2013? Because that's the time
> >Qt
> >will be stuck with MSVC2012.
>
>
> WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.
>
Right, that's what I expected, I'm guessing the expectation is that it'll be
supported for years.

We need to prioritize moving towards modern C++. The C++ world is changing.We
cannot be stuck on a compiler that has only a minimal set of C++11 features,
if we want Qt to stay relevant.

So, I'm against making WEC2013 a supported platform.

daniel

[Knoll Lars]

On 25/06/15 12:43, "Teske Daniel" <***@theqtcompany.com> wrote:

>On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote:
>> On 25/06/15 11:43, "Teske Daniel" <***@theqtcompany.com> wrote:
>>
>>
>> >> * WEC7 not supported anymore, WEC2013 supported
>> >
>> >So what is the time frame for dropping WEC2013? Because that's the time
>> >Qt
>> >will be stuck with MSVC2012.
>>
>>
>> WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.
>>
>Right, that's what I expected, I'm guessing the expectation is that it'll
>be
>supported for years.

Right. But at some point the question will come on which Qt version we
support the platform.
>
>
>We need to prioritize moving towards modern C++. The C++ world is
>changing.We
>cannot be stuck on a compiler that has only a minimal set of C++11
>features,
>if we want Qt to stay relevant.

There’s always a difference between enabling our users to use more modern
C++11 features and us using those ourselves inside our product. Inside the
Qt frameworks, we've always been more conservative in using features
unconditionally that are not supported everywhere.

When we went through the compatibility list during QtCS, it looked like we
can start using quite a few C++11 features unconditionally even with
VS2012. This gives us a much better baseline than what we had previously.

>
>So, I'm against making WEC2013 a supported platform.

Well, please tell me where this is such a big problem that we *have to
have* VS2013 when it comes to our APIs. For our implementation inside Qt,
we can work with slightly older compilers. It’s not the end of the world
and our users wouldn’t even notice.

Cheers,
Lars

[Cristian Adam]

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars <***@theqtcompany.com>
wrote:

>
>
> Well, please tell me where this is such a big problem that we *have to
> have* VS2013 when it comes to our APIs. For our implementation inside Qt,
> we can work with slightly older compilers. It’s not the end of the world
> and our users wouldn’t even notice.
>
> Cheers,
> Lars
>
>
There is always CopperSpice <http://www.copperspice.com/> the Qt fork which
uses C++11.

They've got rid of moc and plan to replace Qt containers with std ones.
Afterwards maybe
they will add support for namespaces to their peppermill source convertor
utility.

Cheers,
Cristian.

[Bubke Marco]

Wrapping Qt container around standard container is quite a good idea to interact with other code. So Qt Container would be standard container + COW. One of the complains I hear very often is that Qt is an island and sadly in many cases I must agree. I think we should discuss the integration of the new library features too.

Cheers, Marco

________________________________
From: development-bounces+marco.bubke=***@qt-project.org <development-bounces+marco.bubke=***@qt-project.org> on behalf of Cristian Adam <***@gmail.com>
Sent: Thursday, June 25, 2015 1:18 PM
To: Knoll Lars
Cc: ***@qt-project.org
Subject: Re: [Development] Qt LTS & C++11 plans

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars <***@theqtcompany.com<mailto:***@theqtcompany.com>> wrote:


Well, please tell me where this is such a big problem that we *have to
have* VS2013 when it comes to our APIs. For our implementation inside Qt,
we can work with slightly older compilers. It's not the end of the world
and our users wouldn't even notice.

Cheers,
Lars


There is always CopperSpice<http://www.copperspice.com/> the Qt fork which uses C++11.

They've got rid of moc and plan to replace Qt containers with std ones. Afterwards maybe
they will add support for namespaces to their peppermill source convertor utility.

Cheers,
Cristian.

[Thiago Macieira]

On Thursday 25 June 2015 13:55:00 Bubke Marco wrote:
> Wrapping Qt container around standard container is quite a good idea to
> interact with other code. So Qt Container would be standard container +
> COW. One of the complains I hear very often is that Qt is an island and
> sadly in many cases I must agree. I think we should discuss the integration
> of the new library features too.

That's a Qt 6 discussion.

Wrapping the std containers with COW will introduce another level of
indirection to the data, which is probably the worst of all solutions. If
we're going to use the std containers in any capacity, we'll have to ditch COW
completely.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Thursday 25 June 2015 13:18:17 Cristian Adam wrote:
> They've got rid of moc and plan to replace Qt containers with std ones.

If they got rid of moc, then they also got rid of QtDBus, QtScript and QtQml.
That doesn't sound like a "fork of Qt".

Getting rid of moc is waiting for SG7 from the standards committee to come up
with a language reflection feature. At the current pace, it might happen as a
TS for C++2x, so we may be able to start using it in Qt around 2025.

And if they replaced Qt containers with std ones, what replaced QString?
Because the standard ones are nowhere near feature parity with QString.
Unfortunately, CopperSpice's documentation is offline, so I can't tell.

Doesn't seem like a serious project to me. That sounds a lot like TQt from the
Trinity Project...

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Al-Khanji Louai]

What they did was to move registration of meta object content to runtime. They basically have structs with static variables and they rely on initialization of these variables at program start-up. It's a lot of macro magic and relies on things like __LINE__ to create unique tokens.

The info above is based on this presentation, the meta object stuff is covered from slide 20 onwards: https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6gwF4SIvGJIE_1tb4P78RN3o/edit?usp=sharing

I don't think they did anything to the container classes, but I haven't looked.

Cheers,
Louai

> -----Original Message-----
> From: development-bounces+louai.al-khanji=***@qt-
> project.org [mailto:development-bounces+louai.al-
> khanji=***@qt-project.org] On Behalf Of Thiago Macieira
> Sent: Thursday, June 25, 2015 7:03 PM
> To: ***@qt-project.org
> Subject: Re: [Development] Qt LTS & C++11 plans
>
> On Thursday 25 June 2015 13:18:17 Cristian Adam wrote:
> > They've got rid of moc and plan to replace Qt containers with std
> ones.
>
> If they got rid of moc, then they also got rid of QtDBus, QtScript and
> QtQml.
> That doesn't sound like a "fork of Qt".
>
> Getting rid of moc is waiting for SG7 from the standards committee to
> come up
> with a language reflection feature. At the current pace, it might
> happen as a
> TS for C++2x, so we may be able to start using it in Qt around 2025.
>
> And if they replaced Qt containers with std ones, what replaced QString?
> Because the standard ones are nowhere near feature parity with QString.
> Unfortunately, CopperSpice's documentation is offline, so I can't tell.
>
> Doesn't seem like a serious project to me. That sounds a lot like TQt
> from the
> Trinity Project...
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Thiago Macieira]

On Friday 26 June 2015 06:12:53 Al-Khanji Louai wrote:
> What they did was to move registration of meta object content to runtime.
> They basically have structs with static variables and they rely on
> initialization of these variables at program start-up. It's a lot of macro
> magic and relies on things like __LINE__ to create unique tokens.
>
> The info above is based on this presentation, the meta object stuff is
> covered from slide 20 onwards:
> https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6gwF4SIvGJIE_1tb
> 4P78RN3o/edit?usp=sharing

I see, thanks.

It doesn't work with -fvisibility-inlines-hidden.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

> There is always CopperSpice the Qt fork which uses C++11. They've
> got rid of moc and plan to replace Qt containers with std ones.
> Afterwards maybe they will add support for namespaces to their
> peppermill source convertor utility.

I am one of the developers of CopperSpice and I would like to
elaborate on our project. Our initial release of CopperSpice was in
July 2014 with our target audience being our local C++ Users Group in
the San Francisco Bay area. We wanted to explore the interest in
CopperSpice and obtain feedback regarding the steps we took to remove
moc. Our full presentation in February 2015 was well received and
attended by several prominent people.

Our intent was to formally announce CopperSpice at CPPCon in
September. Oddly, once we submitted a proposal for speaking at
CPPCon, someone in Europe decided to post information about
CopperSpice on reddit. As of today I can announce we have been
approved to speak about CopperSpice at CPPCon.

The current version of CopperSpice supports the full Qt Metaobject
System, requires C++11, and includes CsCore, CsGui, CsPhonon, as well
as CsScript, and CsWebkit. We have CsDBus partially ported, however
more time has been spent on other libraries. It will be available in
our September release.

I would like to clarify, we did not use anything from the Woboq blog
posting as others have speculated. We had moc removed from CopperSpice
a year earlier than the release of this blog. We are also not
associated with the Trinity Project.

As a consequence of our presentation in February we have modified
parts of the internal registration code to better implement
reflection. We will be making a few more changes before this is
released.

Our September release of CopperSpice will include changes to the
contain library, reimplementation of atomic types, our new changes to
the MetaObject System registration, full API documentation, ??

We would like to encourage developers to attend CPPCon to learn about
modern C++ and where it is going. For more information please check
out the following video.

http://cppcon.org/2015promo/

Our thanks go out to Trolltech, Nokia, and Digia for all the work they
have done.


Ansel Sermersheim
CopperSpice Co-Founder
www.copperspice.com

[Thiago Macieira]

On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote:
> I would like to clarify, we did not use anything from the Woboq blog
> posting as others have speculated. We had moc removed from CopperSpice
> a year earlier than the release of this blog. We are also not
> associated with the Trinity Project.

Out of curiosity:

You've removed moc, but what's your replacement for rcc?

> We would like to encourage developers to attend CPPCon to learn about

Maybe Meeting C++ will get better luck. Most of the Qt developers live in
Europe. I encourage you to submit your session there.

By the way, you're also welcome to discuss your ideas in this mailing list.
We're not against new C++ techniques, but we want to support existing
deployments, so we have to be a little more pragmatic on our choices.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 6/29/15 10:59 PM, Thiago Macieira wrote:
> On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote:
>> I would like to clarify, we did not use anything from the Woboq
>> blog posting as others have speculated. We had moc removed from
>> CopperSpice a year earlier than the release of this blog. We are
>> also not associated with the Trinity Project.
>
> Out of curiosity:
>
> You've removed moc, but what's your replacement for rcc?

I hope I understand your question correctly. By removing moc and not
using qmake, we were able to remove all the bootstrap code from
CsCore. This allowed us to build rcc simply linking with CsCore.

We did not see any reason to replace rcc at this time. Our goal was to
allow developers to use CopperSpice without altering their build systems.
Since the resource system is not mandatory we did not feel like an
alternative to rcc was required.

>> We would like to encourage developers to attend CPPCon to learn
>> about
>
> Maybe Meeting C++ will get better luck. Most of the Qt developers
> live in Europe. I encourage you to submit your session there.
>
> By the way, you're also welcome to discuss your ideas in this mailing
> list. We're not against new C++ techniques, but we want to support
> existing deployments, so we have to be a little more pragmatic on our
> choices.
>

Thank you for your warm welcome and encouragement.

Ansel Sermersheim
CopperSpice Co-Founder
www.copperspice.com

[Alejandro Exojo]

El Tuesday 30 June 2015, Ansel Sermersheim escribió:
> Our September release of CopperSpice will include changes to the
> contain library, reimplementation of atomic types, our new changes to
> the MetaObject System registration, full API documentation, ??
>
> We would like to encourage developers to attend CPPCon to learn about
> modern C++ and where it is going. For more information please check
> out the following video.
>
> http://cppcon.org/2015promo/

Can you explain which are your long term plans? Given that you renamed all the
classes and modules (or so I understood), this is full source incompatible,
and it doesn't seem like you want to sync again with the original Qt
(applications might include a large file full of typedefs, but applying to
CopperSpice any bugfix patch found in Qt seems completely manual). Some
developers experiment with their own branches to research or have fun, which
is great, but seems like you are aiming to be a full new project.

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

[Ansel Sermersheim]

On 6/29/15 11:37 PM, Alejandro Exojo wrote:
> El Tuesday 30 June 2015, Ansel Sermersheim escribió:
>> Our September release of CopperSpice will include changes to the
>> contain library, reimplementation of atomic types, our new changes
>> to the MetaObject System registration, full API documentation, ??
>>
>> We would like to encourage developers to attend CPPCon to learn
>> about modern C++ and where it is going. For more information please
>> check out the following video.
>>
>> http://cppcon.org/2015promo/
>
> Can you explain which are your long term plans? Given that you
> renamed all the classes and modules (or so I understood), this is
> full source incompatible, and it doesn't seem like you want to sync
> again with the original Qt (applications might include a large file
> full of typedefs, but applying to CopperSpice any bugfix patch found
> in Qt seems completely manual). Some developers experiment with
> their own branches to research or have fun, which is great, but
> seems like you are aiming to be a full new project.

We renamed the libraries to avoid naming conflicts with the Qt libraries
when CS and Qt are installed on the same system. We have not renamed the
classes, and our intention is to keep source compatibility as much as
possible. Some incompatible changes were unavoidable, particularly the
signal / slot declaration syntax.

Our goal with CopperSpice is to use modern C++ internally to leverage
everything we can from the language. We want developers of CopperSpice
applications to have the full power of C++ available in all parts of
their code. For example, with moc removed we support template classes
that inherit from QObject. We support passing method pointers as signal
arguments.

We would like to support multiple inheritance properly. We would like
the CsGui classes to work seamlessly with STL containers, and to add
things like reverse iterators to the CS container library to bring it in
line with the STL. We are going to fully support exceptions, and make
exception safety guarantees where possible. We are working on
redesigning the QObject lifetime model so that it works smoothly with
C++11 smart pointers.

These are some of the limitations that frustrated us when using Qt in an
existing codebase.

Thank you very much for your question,

Ansel Sermersheim
CopperSpice Co-Founder
www.copperspice.com

[Thiago Macieira]

On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote:
> Our goal with CopperSpice is to use modern C++ internally to leverage
> everything we can from the language. We want developers of CopperSpice
> applications to have the full power of C++ available in all parts of
> their code. For example, with moc removed we support template classes
> that inherit from QObject. We support passing method pointers as signal
> arguments.

You need to use -fvisibility-inlines-hidden and retry. I don't think your
solution works under those circumstances.

> We are going to fully support exceptions, and make
> exception safety guarantees where possible.

Unless you're going to rewrite the entire GUI, widgets, networking and other
libraries from scratch, you're not going to get exception-safety.

> We are working on
> redesigning the QObject lifetime model so that it works smoothly with
> C++11 smart pointers.

I researched that 4 or 5 years ago and I found two problems:

First, you must either choose to use smart pointers everywhere or not at all.
You can't pick and choose, which is what caused most of the problems.

Second, and most importantly, all the QWidget-derived classes share state with
their parent widgets. You MUST delete the children when the parent is getting
deleted, which is incompatible with smart pointers. Like I said above for
exceptions, you'll need to redesign the entire stack to get support for smart
pointers here.

> These are some of the limitations that frustrated us when using Qt in an
> existing codebase.

You're making trade-offs. One of them, given your presentation, is that there's
no current version of MSVC that will work with your codebase. Another is that
you're replacing a code generator by a lot of boilerplate macros.

And, critically, like I mentioned above, is that I don't think your solution
works with -fvisibility-inlines-hidden, due to taking and comparing addresses
of inline functions.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Cristian Adam]

On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira <***@intel.com
> wrote:

>
> You're making trade-offs. One of them, given your presentation, is that
> there's
> no current version of MSVC that will work with your codebase. Another is
> that
> you're replacing a code generator by a lot of boilerplate macros.
>
>
Visual Studio 2015 will have constexpr fixed [1] and it should compile
CopperSpice.

The replacement of qmake with autotools in CopperSpice makes things very
hard to
test with Visual Studio. It seems CMake is being under evaluation [2].

The combination of CMake and ninja is quite effective.

Cheers,
Cristian.


[1]
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx
[2] http://forum.copperspice.com/viewtopic.php?f=10&t=7

[Thiago Macieira]

On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote:
> On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira <***@intel.com
> > wrote:
> >
> >
> > You're making trade-offs. One of them, given your presentation, is that
> > there's
> > no current version of MSVC that will work with your codebase. Another is
> > that
> > you're replacing a code generator by a lot of boilerplate macros.
>
> Visual Studio 2015 will have constexpr fixed [1] and it should compile
> CopperSpice.

It's still not working in MSVC 2015 RC1. I'd be wary of relying on RTM fixing
it if it's still not fixed yet.

> The replacement of qmake with autotools in CopperSpice makes things very
> hard to
> test with Visual Studio. It seems CMake is being under evaluation [2].
>
> The combination of CMake and ninja is quite effective.

Autotools is backwards direction. Everyone moves *away* from Autotools, not
towards it (except people who had no buildsystem in the first place).

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 6/30/15 1:01 PM, Thiago Macieira wrote:
> On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote:
>> Our goal with CopperSpice is to use modern C++ internally to leverage
>> everything we can from the language. We want developers of CopperSpice
>> applications to have the full power of C++ available in all parts of
>> their code. For example, with moc removed we support template classes
>> that inherit from QObject. We support passing method pointers as signal
>> arguments.
>
> You need to use -fvisibility-inlines-hidden and retry. I don't think your
> solution works under those circumstances.

As we mentioned we have already changed parts of the CopperSpice
registration system. This will be released within the next month or so.
We are definitely aware of -fvisibility-inlines-hidden, and we will look
into supporting it.

>> We are going to fully support exceptions, and make
>> exception safety guarantees where possible.
>
> Unless you're going to rewrite the entire GUI, widgets, networking and other
> libraries from scratch, you're not going to get exception-safety.

Yes, many parts will need to be redone and we are starting with the
container classes.

>> These are some of the limitations that frustrated us when using Qt in an
>> existing codebase.
>
> You're making trade-offs. One of them, given your presentation, is that there's
> no current version of MSVC that will work with your codebase. Another is that
> you're replacing a code generator by a lot of boilerplate macros.

We do not feel that requiring a compiler to support C++11 is
unreasonable. Our main issues with MSVC is with constexpr and expression
SFINAE. MS has added partial support of constexpr for MSVC 2015,
although they are still reported to have a few issues. They will get
there eventually. No word yet on when expression SFINAE will be added.

Yes, we make use of macros as macros were intended to be used. We
strongly believe the syntax for our macros is concise and clean, and
that this tradeoff is worthwhile.

Ansel
CopperSpice Co-Founder
www.copperspice.com

[Thiago Macieira]

On Tuesday 30 June 2015 19:40:55 Ansel Sermersheim wrote:
> > Unless you're going to rewrite the entire GUI, widgets, networking and
> > other libraries from scratch, you're not going to get exception-safety.
>
> Yes, many parts will need to be redone and we are starting with the
> container classes.

You may be underestimating the effort required. You'll need to spend a couple
of man-decades of work to get this done...

> >> These are some of the limitations that frustrated us when using Qt in an
> >> existing codebase.
> >
> > You're making trade-offs. One of them, given your presentation, is that
> > there's no current version of MSVC that will work with your codebase.
> > Another is that you're replacing a code generator by a lot of boilerplate
> > macros.
>
> We do not feel that requiring a compiler to support C++11 is
> unreasonable. Our main issues with MSVC is with constexpr and expression
> SFINAE. MS has added partial support of constexpr for MSVC 2015,
> although they are still reported to have a few issues. They will get
> there eventually. No word yet on when expression SFINAE will be added.

And that's where we disagree. We feel that we have to be pragmatic and support
compilers that people have access to. This is exactly why this thread started.

I'm not saying you can't do what you're doing. I'm simply saying it's a trade-
off. You're trading a potentially large userbase for the ability to use those
C++11 features.

> Yes, we make use of macros as macros were intended to be used. We
> strongly believe the syntax for our macros is concise and clean, and
> that this tradeoff is worthwhile.

No doubt you do. But I still disagree.

My opinion is that a code generator is far preferable to boilerplate macros.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Bernhard]

> For example, with moc removed we support template classes that inherit
> from QObject.

Wow. I would (almost) kill for having that feature in Qt!

--
Regards
Bernhard Lindner

[Olivier Goffart]

On Tuesday 30. June 2015 22:37:24 Bernhard wrote:
> > For example, with moc removed we support template classes that inherit
> > from QObject.
>
> Wow. I would (almost) kill for having that feature in Qt!

You can do that with moc.

https://codereview.qt-project.org/49864/

There was a discussion about it on the mailinglist at the time, but nobody
expressed much interest in having that feature.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

[Thiago Macieira]

On Wednesday 01 July 2015 00:49:19 Olivier Goffart wrote:
> On Tuesday 30. June 2015 22:37:24 Bernhard wrote:
> > > For example, with moc removed we support template classes that inherit
> > > from QObject.
> >
> > Wow. I would (almost) kill for having that feature in Qt!
>
> You can do that with moc.
>
> https://codereview.qt-project.org/49864/
>
> There was a discussion about it on the mailinglist at the time, but nobody
> expressed much interest in having that feature.

The feature is probably affected by the -fvisibility-inlines-hidden issue too.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Julien Blanc]

Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit :

> > For example, with moc removed we support template classes that inherit
> > from QObject.
>
> Wow. I would (almost) kill for having that feature in Qt!
>


You can work around it quite easily. What doesn’t work is adding new
signals / slots inside a template class. So just add a base class
declaring these signals/slots, and make your template class inherits
from it.

Unless you wan’t to use the template class as signal/slots arguments,
this works fine.

Regards,

Julien

[charleyb123 .]

>
> > For example, with moc removed we support template classes that inherit> from QObject.
>
> Wow. I would (almost) kill for having that feature in Qt!
>
> You can work around it quite easily. What doesn’t work is adding new
> signals / slots inside a template class. So just add a base class declaring
> these signals/slots, and make your template class inherits from it.
>
> Unless you wan’t to use the template class as signal/slots arguments, this
> works fine.
>
> Regards,
>
> Julien
>

+1.

I do that a lot:

QObject <= MyClass <= MyTemplate <= MyClassDerived

--charley

[Bernhard]

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.



--

Kind Regards

Bernhard Lindner



Von: development-bounces+private=bernhard-***@qt-project.org [mailto:development-bounces+private=bernhard-***@qt-project.org] Im Auftrag von Julien Blanc
Gesendet: Mittwoch, 1. Juli 2015 09:16
An: ***@qt-project.org
Betreff: Re: [Development] Qt LTS & C++11 plans (CopperSpice)



Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit :


> For example, with moc removed we support template classes that inherit
> from QObject.

Wow. I would (almost) kill for having that feature in Qt!



You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it.

Unless you wan’t to use the template class as signal/slots arguments, this works fine.

Regards,

Julien

[Thiago Macieira]

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.

The problem in doing this is how to create the meta object so that runtime
reflection works.

Using the template parameter(s) inside the class leads to HUGE complexity.
Think of something horribly complex: you're probably only two orders of
magnitude away from the real complexity.

One way of doing this would be to drop the meta object and the runtime
reflection. That would also get rid of QtScript, QtQml, QtDBus, ActiveQt,
QtWebKit's registering of QObjects, etc. It's a complete non-starter.

Another way is to do it like CopperSpice is doing, by way of boilerplate
macros and manual runtime registration, at the expense of making the code
(subjectively) harder to read and of runtime cost. Qt's current[1] meta object
system is *entirely* read-only, shared memory, except for the QMetaObject
structure itself, which is read-only data with local relocations[2]. This is
much beyond pure C++: we're investigating performance, code size, data size,
relocation count, etc.

[1] Current, because it wasn't so before Qt 4. So you see that this has 15
years of learnings applied.

[2] Local relocations, as opposed to global relocations, are much faster to
resolve, as they have no symbol name to be looked up. Also, local relocations
disappear on position-dependent code, which we'll get back to allowing once
GCC introduces the necessary options.

PS: I've just got an idea for getting rid of the relocations on
Linux/x86-64... I need to check if there's a way of doing it before Qt 6.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Milian Wolff]

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?

Bye
--
Milian Wolff | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: [phone]
KDAB - The Qt Experts

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


Ansel Sermersheim
CopperSpice Co-Founder
www.copperspice.com

[Thiago Macieira]

On Thursday 02 July 2015 22:09:13 Ansel Sermersheim wrote:
> 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.

You have Microsoft to thank for that. Dropping something like 40% of our
userbase is not worth constexprs.

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

On the other hand, existing Qt programmers will feel right at home and their
existing applications will continue to run.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Bo Thorsen]

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

[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

[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 | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: [phone]
KDAB - The Qt Experts

[Thiago Macieira]

On Friday 03 July 2015 09:42:54 Milian Wolff wrote:
> 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).

That said, there are a couple of places where smart use of smart pointers
could improve Qt API.

For example, a lot of I/O code takes a QIODevice*, but does not transfer
ownership. Which means those classes often have a getter that gives you that
QIODevice *. The problem is that there are other places that are QIODevice
factories, like QNAM (QNetworkReply).

Is there anything that would help people know when a pointer's ownership is
transferred instead of just the documentation? Probably std::unique_ptr.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 7/2/15 2:00 PM, 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.

This is exactly one of the major reasons that we started CopperSpice.
When working with the Model/View framework there are many situations
where one wants to use a templated model. It's possible to get the same
end result with some creative use of multiple inheritance, but it is a
very unpleasant hack.

Given several comments we have seen, it sounds like this is not the
direction Qt is going for many years if at all.

Ansel Sermersheim
CopperSpice Co-Founder
www.copperspice.com

[Marc Mutz]

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.

Then you should have used Boost.Signals.

Qt is not the only C++ library out there, and asking it to be everything for
everyone is unreasonable.

That said, in my experience, if you want signals on templates, you're usually
going it wrong. You probably intend to use it far away from the GUI layout,
maybe even in your cenral data model (!= QAbstractItemModel here). Overuse of
signal-slots can make a program very hard to understand, and possibly also
slow. If you don't believe, I invite you to study pre-Akonadi KMail code.

Thanks,
Marc

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Konstantin Tokarev]

30.06.2015, 23:38, "Bernhard" <***@bernhard-lindner.de>:
>>  For example, with moc removed we support template classes that inherit
>>  from QObject.
>
> Wow. I would (almost) kill for having that feature in Qt!

http://www.labri.fr/perso/guenneba/code/ppmoc.php

No C++11 required (code was written in 2008 or earlier)

--
Regards,
Konstantin

[Simon Hausmann]

On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote:
> > There is always CopperSpice the Qt fork which uses C++11. They've
> > got rid of moc and plan to replace Qt containers with std ones.
> > Afterwards maybe they will add support for namespaces to their
> > peppermill source convertor utility.
>
> I am one of the developers of CopperSpice and I would like to
> elaborate on our project. Our initial release of CopperSpice was in
> July 2014 with our target audience being our local C++ Users Group in
> the San Francisco Bay area. We wanted to explore the interest in
> CopperSpice and obtain feedback regarding the steps we took to remove
> moc. Our full presentation in February 2015 was well received and
> attended by several prominent people.

I for one welcome your efforts. I think it's great that you're trying out new
things on the shoulders of Qt. To me this feels healthy and I'm at this point
not worried about fragmentation. Experimentation is something we should
encourage, even if those experiments happen in deep core parts of the
framework. I'm also glad to see that you're sharing your work with the rest of
the development community on github.

It would be great if some of your improvements, some of your innovations could
- in the future - find their way back to Qt. It's not evident at this point
how exactly, but I think it would be good to keep it in the back of our heads.


That said, I did see the slides of your presentation in February 2015 and I am
disappointed about the slide with the heading "Why we developed CopperSpice".
It says that one of the reasons was that "Libraries not developed as a true
open source project". This is disappointing for me to read. Thiago, Lars and
others who have worked on the governance rules of Qt have done tremendous work
to establish the true open source umbrella, especially by learning from other
projects and taking the experience into account when formulating the
contribution and governance guidelines.

I hope that in future presentations of your project you are not going to give
your audience the impression that Qt is not a true open source project.


Simon

[Ansel Sermersheim]

We would like to announce our release of CopperSpice 1.1.0. We have
added and changed several things including a modification to to QMap to
user defined comparisons. We have a timeline others may be interested in
viewing in our overview documentation. We will have API documentation
uploaded by Aug 15.

http://www.copperspice.com/docs/cs_overview/timeline.html

Barbara spent a good deal of time reviewing the CLA for Qt. We
appreciate the work Thiago and Lars have done on the CLA and
contribution guidelines. On every thread she read and with people she
spoke with, there was always several who expressed concerns. We even had
a nice chat with Tobias Hunger about this issue.

Our view as well as the view from many other developers, is that the CLA
gives the Qt Project the freedom to take any and all submissions and
incorporate them into the closed source version. We feel this goes
against the share and share alike principle of community based open
source software.

From the countless local developers in the Silicon Valley area we have
communicated with, Qt is not typically viewed as a community project.
There is nothing inherently wrong with this approach, it just did not
fit our paradigm.

We are speaking at CPPCon in September and our intent is simply to
explain the CLA did not work for us. The main purpose of our
presentation is to present CopperSpice and offer C++ developers an
alternative GUI library.

Ansel


On 7/3/15 12:52 AM, Simon Hausmann wrote:
> On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote:
>>> There is always CopperSpice the Qt fork which uses C++11. They've
>>> got rid of moc and plan to replace Qt containers with std ones.
>>> Afterwards maybe they will add support for namespaces to their
>>> peppermill source convertor utility.
>> I am one of the developers of CopperSpice and I would like to
>> elaborate on our project. Our initial release of CopperSpice was in
>> July 2014 with our target audience being our local C++ Users Group in
>> the San Francisco Bay area. We wanted to explore the interest in
>> CopperSpice and obtain feedback regarding the steps we took to remove
>> moc. Our full presentation in February 2015 was well received and
>> attended by several prominent people.
> I for one welcome your efforts. I think it's great that you're trying out new
> things on the shoulders of Qt. To me this feels healthy and I'm at this point
> not worried about fragmentation. Experimentation is something we should
> encourage, even if those experiments happen in deep core parts of the
> framework. I'm also glad to see that you're sharing your work with the rest of
> the development community on github.
>
> It would be great if some of your improvements, some of your innovations could
> - in the future - find their way back to Qt. It's not evident at this point
> how exactly, but I think it would be good to keep it in the back of our heads.
>
>
> That said, I did see the slides of your presentation in February 2015 and I am
> disappointed about the slide with the heading "Why we developed CopperSpice".
> It says that one of the reasons was that "Libraries not developed as a true
> open source project". This is disappointing for me to read. Thiago, Lars and
> others who have worked on the governance rules of Qt have done tremendous work
> to establish the true open source umbrella, especially by learning from other
> projects and taking the experience into account when formulating the
> contribution and governance guidelines.
>
> I hope that in future presentations of your project you are not going to give
> your audience the impression that Qt is not a true open source project.
>
>
> Simon

[Gunnar Roth]

Hi Ansel.
> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim <***@copperspice.com>:
>
> gives the Qt Project the freedom to take any and all submissions and
> incorporate them into the closed source version

Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license.
Btw. It is not Qt Project , it is Qt Company.

[Marc Mutz]

On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote:
> Hi Ansel.
>
> > Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim <***@copperspice.com>:
> >
> > gives the Qt Project the freedom to take any and all submissions and
> > incorporate them into the closed source version
>
> Do not mix up commercial license with closed source, all code you
> contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules
> AND the commercial license. Btw. It is not Qt Project , it is Qt Company.

Note how it's copperspice._com_, not .org :) Will be interesting to see how
they want to make money off their project. Or how they deal with the problem
of relicensing once they grow to 200 instead of 2 developers...

Thanks,
Marc

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Ansel Sermersheim]

Hi Marc,

We do own copperspice.com, .org, .net, and .info. We set .com up as the
primary site for no particular reason.

There is no question that making money is of value. However, our main
goal at this time is to develop CopperSpice and share it with the
community. We believe money will follow but it is not our primary goal
or direction.

We have a few beta testers, an excellent project mentor, a couple of
people contributing changes, and we are working with someone on the
packaging process with various unix distributions

As to your question about relicensing, can you please elaborate on what
this is referring to? As long as Qt is covered by the current license,
we can not relicense CopperSpice since we are bound by the terms of the
licenses under which we forked the code.

Ansel Sermersheim

On 7/21/15 12:36 PM, Marc Mutz wrote:
> On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote:
>> Hi Ansel.
>>
>>> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim <***@copperspice.com>:
>>>
>>> gives the Qt Project the freedom to take any and all submissions and
>>> incorporate them into the closed source version
>> Do not mix up commercial license with closed source, all code you
>> contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules
>> AND the commercial license. Btw. It is not Qt Project , it is Qt Company.
> Note how it's copperspice._com_, not .org :) Will be interesting to see how
> they want to make money off their project. Or how they deal with the problem
> of relicensing once they grow to 200 instead of 2 developers...
>
> Thanks,
> Marc
>

[Pau Garcia i Quiles]

On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim <***@copperspice.com>
wrote:

As to your question about relicensing, can you please elaborate on what
> this is referring to? As long as Qt is covered by the current license,
> we can not relicense CopperSpice since we are bound by the terms of the
> licenses under which we forked the code.
>
>
I think the actual question(s) were:


- Are you and Barbara developing CopperSpice full-time, part-time or
just on your spare time?

- How do you sustain development of CopperSpice? Support & services to
Qt4 delopers? You use it only for your own (paid-for) projects? Venture
Capital? No funding at all, just hobby?


And I would repeat the question Milian asked: why did you fork Qt4 instead
of Qt5?

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

[Marc Mutz]

On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote:
> As to your question about relicensing, can you please elaborate on what
> this is referring to? As long as Qt is covered by the current license,
> we can not relicense CopperSpice since we are bound by the terms of the
> licenses under which we forked the code.

You own the copyright to those parts which you added. Come GPL4, you might
conceivably want to use that license. Assuming TQC releases its code under
GPL4, too, which it can, that leaves your own original work. Assuming it's
just you and Barbara, you won't have problems. But if you have 200
contributors, half of which vanished from the face of the earth after a few
months of being active, you will have a harder time to track every contributor
down and get approval for the relicensing from each of them. It's why many
Free Software projects require some form of copyright assignment, incl. the
Godfather of GPL projects, GNU.

You seem to say that Copperspice is in some sense more free than Qt, because
of the missing CLA, but you may have locked yourself into a set of licenses
forever, like the Linux kernel did (and it's anyone's guess whether Linus is
*actually* happy with the GPL v2 and being stuck with it forever, or whether
dropping the "or later" clause secretly gnaws at his conscience, after all he
also publicly condemns C++ and then goes to write his diving app in Qt/C++ :)

IANAL, yadda, yadda,
Marc

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Thiago Macieira]

On Wednesday 22 July 2015 00:15:19 Marc Mutz wrote:
> You own the copyright to those parts which you added. Come GPL4, you might
> conceivably want to use that license. Assuming TQC releases its code under
> GPL4, too, which it can, that leaves your own original work. Assuming it's
> just you and Barbara, you won't have problems. But if you have 200
> contributors, half of which vanished from the face of the earth after a few
> months of being active, you will have a harder time to track every
> contributor down and get approval for the relicensing from each of them.
> It's why many Free Software projects require some form of copyright
> assignment, incl. the Godfather of GPL projects, GNU.

To be fair, those projects often limit the set of licences that the code can
be relicensed under. For example, KDE requires all inbound contributions to be
either:

GPLv2, GPLv3 or later
GPLv2, GPLv3 or any later version by a decision of the KDE e.V.

That is, even if the e.V. wanted to, it could not relicense under, say, the
Apache licence version 2. It has to be an upgrade of the GPL.

The KDE Free Qt Foundation requires relicensing under the terms of the BSD
licence. No other.

Other projects may limit to licenses approved by the Open Source Initiative.
Some others may say OSI approved *and* copyleft.

In the specific case of the Qt Project CLA, it makes no judgement. It can be
any license, including non-open source ones. Which is the case.


And since I'm being fair: the CLA is required by the KDE Free Qt Foundation,
since The Qt Company has to have the rights to relicense everything under the
BSD license. The only other option would be to have all inbound contributions
under the BSD licence.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 7/21/15 3:15 PM, Marc Mutz wrote:
> On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote:
>> As to your question about relicensing, can you please elaborate on what
>> this is referring to? As long as Qt is covered by the current license,
>> we can not relicense CopperSpice since we are bound by the terms of the
>> licenses under which we forked the code.
> You own the copyright to those parts which you added. Come GPL4, you might
> conceivably want to use that license. Assuming TQC releases its code under
> GPL4, too, which it can, that leaves your own original work. Assuming it's
> just you and Barbara, you won't have problems. But if you have 200
> contributors, half of which vanished from the face of the earth after a few
> months of being active, you will have a harder time to track every contributor
> down and get approval for the relicensing from each of them. It's why many
> Free Software projects require some form of copyright assignment, incl. the
> Godfather of GPL projects, GNU.

As we mentioned, we have several people testing CopperSpice as well as
others asking about how to contribute to the project. We certainly look
forward to having an active development community.

We do in fact have a CLA in place. However, our CLA has one single
purpose. In the event that Qt is re-licensed under a BSD style license
(whether due to the KDE Free Qt Foundation or some other reason), we
will re-license CopperSpice under that same license. That is the only
permission we ask from contributors.

> You seem to say that Copperspice is in some sense more free than Qt, because
> of the missing CLA, but you may have locked yourself into a set of licenses
> forever, like the Linux kernel did (and it's anyone's guess whether Linus is
> *actually* happy with the GPL v2 and being stuck with it forever, or whether
> dropping the "or later" clause secretly gnaws at his conscience, after all he
> also publicly condemns C++ and then goes to write his diving app in Qt/C++ :)
Just to be clear, we are not opposed to a CLA and as noted above we have
one as well. We simply did not feel comfortable contributing under the
Qt Company CLA for reasons which we have previously stated.

We do understand and appreciate the logic and the financial reasons that
led to the Qt Company CLA.

Ansel Sermersheim

[Kevin Kofler]

Ansel Sermersheim wrote:
> We do in fact have a CLA in place. However, our CLA has one single
> purpose. In the event that Qt is re-licensed under a BSD style license
> (whether due to the KDE Free Qt Foundation or some other reason), we
> will re-license CopperSpice under that same license. That is the only
> permission we ask from contributors.

That in turn allows everyone else, or even you, to take the code
proprietary, so in the case this clause is triggered (which depends on Qt,
i.e., neither on you nor on the contributor), it is functionally equivalent
to a CLA allowing proprietary relicensing.

Kevin Kofler

[Ansel Sermersheim]

On 7/26/15 3:01 PM, Kevin Kofler wrote:
> Ansel Sermersheim wrote:
>> We do in fact have a CLA in place. However, our CLA has one single
>> purpose. In the event that Qt is re-licensed under a BSD style license
>> (whether due to the KDE Free Qt Foundation or some other reason), we
>> will re-license CopperSpice under that same license. That is the only
>> permission we ask from contributors.
> That in turn allows everyone else, or even you, to take the code
> proprietary, so in the case this clause is triggered (which depends on Qt,
> i.e., neither on you nor on the contributor), it is functionally equivalent
> to a CLA allowing proprietary relicensing.
There is one fundamental difference between the CopperSpice and Qt
licensing situation.

In the (unlikely) event that CopperSpice becomes BSD licensed, it
becomes BSD licensed for everyone. This means anyone, anywhere, has
equal rights to make changes and profit from them.

This is very different from one particular entity owning the right to
profit from an open source project. The argument between GPL-style vs
BSD-style licenses is as old as the hills, but both licenses do treat
all contributors equally.

Ansel Sermersheim

[André Somers]

Op 27-7-2015 om 03:47 schreef Ansel Sermersheim:
> On 7/26/15 3:01 PM, Kevin Kofler wrote:
>> Ansel Sermersheim wrote:
>>> We do in fact have a CLA in place. However, our CLA has one single
>>> purpose. In the event that Qt is re-licensed under a BSD style license
>>> (whether due to the KDE Free Qt Foundation or some other reason), we
>>> will re-license CopperSpice under that same license. That is the only
>>> permission we ask from contributors.
>> That in turn allows everyone else, or even you, to take the code
>> proprietary, so in the case this clause is triggered (which depends on Qt,
>> i.e., neither on you nor on the contributor), it is functionally equivalent
>> to a CLA allowing proprietary relicensing.
> There is one fundamental difference between the CopperSpice and Qt
> licensing situation.
>
> In the (unlikely) event that CopperSpice becomes BSD licensed, it
> becomes BSD licensed for everyone. This means anyone, anywhere, has
> equal rights to make changes and profit from them.
>
> This is very different from one particular entity owning the right to
> profit from an open source project. The argument between GPL-style vs
> BSD-style licenses is as old as the hills, but both licenses do treat
> all contributors equally.
>
> Ansel Sermersheim
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
I am not a lawer and I don't know the wording of the KDE Free Qt
Foundation agreement, but are you sure that in case that agreement is
triggered the verion you branched off off will fall under that licence
and be the one that will be released under BSD? I'm just wondering if
all versions would retroactively be relicenced or just the current
code... _If_ it is the latter, you have a problem in your CLA, as you
may not have the right to do the BSD relicencing you promissed seeing
that you forked Qt 4 and not 5...

André

[Thiago Macieira]

On Monday 27 July 2015 08:01:53 André Somers wrote:
> I am not a lawer and I don't know the wording of the KDE Free Qt
> Foundation agreement, but are you sure that in case that agreement is
> triggered the verion you branched off off will fall under that licence
> and be the one that will be released under BSD? I'm just wondering if
> all versions would retroactively be relicenced or just the current
> code... _If_ it is the latter, you have a problem in your CLA, as you
> may not have the right to do the BSD relicencing you promissed seeing
> that you forked Qt 4 and not 5...

https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg

The section 2 says "grants the Foundation [...] the right and license, to use,
copy, duplicate [...] any and all existing and future Qt Free Edition releases
..."

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Andre Somers]

On 27-7-2015 18:21, Thiago Macieira wrote:
> On Monday 27 July 2015 08:01:53 André Somers wrote:
>> I am not a lawer and I don't know the wording of the KDE Free Qt
>> Foundation agreement, but are you sure that in case that agreement is
>> triggered the verion you branched off off will fall under that licence
>> and be the one that will be released under BSD? I'm just wondering if
>> all versions would retroactively be relicenced or just the current
>> code... _If_ it is the latter, you have a problem in your CLA, as you
>> may not have the right to do the BSD relicencing you promissed seeing
>> that you forked Qt 4 and not 5...
> https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg
>
> The section 2 says "grants the Foundation [...] the right and license, to use,
> copy, duplicate [...] any and all existing and future Qt Free Edition releases
> ..."
>
So, the foundation has the right, but not the obligation to do so. So
they probably will, but that's not an automatic given. Thanks for the
link and quote.

André

[Thiago Macieira]

On Tuesday 28 July 2015 06:19:03 Andre Somers wrote:
> > The section 2 says "grants the Foundation [...] the right and license, to
> > use, copy, duplicate [...] any and all existing and future Qt Free
> > Edition releases ..."
>
> So, the foundation has the right, but not the obligation to do so. So
> they probably will, but that's not an automatic given. Thanks for the
> link and quote.

Well, the passage is legalese for saying that the Foundation gets all rights
to the source code. What the Foundation does with the source code is its own
decision.

It can:
a) do nothing and let the code die
b) release it to an open source project under BSD licence
c) ditto, but using LGPL
d) give it to a company to commercialise it under the dual licensing scheme
again
e) something else, but the options b, c,and d are the most likely ones

The important thing to note is that the source code reverting to the
Foundation does not imply neither the end of either the open source project
nor the end of commercial licensing.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

Hi Gunnar,

We used to say "Qt" which we thought was the name of the project. We
were asked to use the name "The Qt Project". We do not mind changing
how we address the company and the library. Since we meant to harm may
we suggest this be conveyed to others a little more gently.

As to your comment regarding licensing, I will quote from the current Qt
CLA, Section 3.1:
> Subject to the terms and conditions of this Agreement, Licensor hereby
> grants, in exchange for good and valuable consideration, the receipt
> and sufficiency of which is hereby acknowledged, to The Qt Company a
> sublicensable, irrevocable, perpetual, worldwide, non-exclusive,
> royalty-free and fully paid-up copyright and trade secret license to
> reproduce, adapt, translate, modify, and prepare derivative works of,
> publicly display, publicly perform, sublicense, make available and
> distribute Licensor Contribution(s) and any derivative works thereof
> under license terms of The Qt Company’s choosing including any Open
> Source Software license.
I am not a lawyer but this language is very clear. It may not be The Qt
Company policy or practice to accept changes into the commercial version
only, but if I were to sign the CLA I would be granting them the right,
irrevocably and perpetually. Since these rights are transferable I have
no recourse if the license is transferred to another entity who uses my
contribution in a way I did not intend.

Most open source development communities are structured in such a way
that all participants have equal rights. The Qt Company is in a position
to exercise additional rights not enjoyed by the rest of the Qt
community. This is certainly a legal and enforceable position. However,
it bothers many members of the larger open source community including
myself.

We have talked with other developers and read discussions about this for
over a decade. Many members of the larger open source community,
including myself, are not comfortable with this clause.

Ansel Sermersheim

On 7/21/15 10:53 AM, Gunnar Roth wrote:
> Hi Ansel.
>> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim
>> <***@copperspice.com <mailto:***@copperspice.com>>:
>>
>> gives the Qt Project the freedom to take any and all submissions and
>> incorporate them into the closed source version
>
> Do not mix up commercial license with closed source, all code you
> contribute will be licensed under GPL,LGPL V2.1 or V3 for newer
> modules AND the commercial license.
> Btw. It is not Qt Project , it is Qt Company.
>
>

[Thiago Macieira]

On Tuesday 21 July 2015 12:21:35 Ansel Sermersheim wrote:
> Hi Gunnar,
>
> We used to say "Qt" which we thought was the name of the project. We
> were asked to use the name "The Qt Project". We do not mind changing
> how we address the company and the library. Since we meant to harm may
> we suggest this be conveyed to others a little more gently.

The point is that there's a difference between:

Qt the product, the framework, the libraries
Qt Project the open source project organised to develop Qt
The Qt Company the company that holds the rights under the CLA and
the trademark to Qt

And, for that matter,
Qt Creator the IDE
(lots of people come on IRC and say something about Qt, when they meant Qt
Creator)

> I am not a lawyer but this language is very clear. It may not be The Qt
> Company policy or practice to accept changes into the commercial version
> only, but if I were to sign the CLA I would be granting them the right,
> irrevocably and perpetually. Since these rights are transferable I have
> no recourse if the license is transferred to another entity who uses my
> contribution in a way I did not intend.

That's actually common practice. The commercial version is identical to the
open source version in functionality and codebase. The reverse is required by
the KDE Free Qt Foundation: everything released commercially must be present
in the open source version (at least, as long as it's Android or X11, but in
practice it is the case for all platforms).

It makes no sense to keep two separate trees. Even when Trolltech had pieces
of functionality that weren't present in the open source version, Trolltech
kept a single tree. The release scripts simply removed some files before the
release.

That hasn't been the case since March 2009. When the Git repositories opened.

> Most open source development communities are structured in such a way
> that all participants have equal rights. The Qt Company is in a position
> to exercise additional rights not enjoyed by the rest of the Qt
> community. This is certainly a legal and enforceable position. However,
> it bothers many members of the larger open source community including
> myself.

Understandable. For us, it's a trade-off: the community accepts giving The Qt
Company some extra rights in exchange for them employing a large chunk of the
work force, including the entirety of the QA team and running the entire CI
system and infrastructure for us.

> We have talked with other developers and read discussions about this for
> over a decade. Many members of the larger open source community,
> including myself, are not comfortable with this clause.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote:
> We would like to announce our release of CopperSpice 1.1.0. We have
> added and changed several things including a modification to to QMap to
> user defined comparisons.

As opposed to qMapLessThanKey? Do you mean two QMap with the same key could
have different comparators?

> Our view as well as the view from many other developers, is that the CLA
> gives the Qt Project the freedom to take any and all submissions and
> incorporate them into the closed source version. We feel this goes
> against the share and share alike principle of community based open
> source software.

True.

It's intended instead to support the "virtuous cycle" that Trolltech talked
about: the commercial version helps fund the development of the open source
version. Shut down the commercial version and the well runs dry. We wouldn't
be able to sustain the development pace we currently have.

All other attempts at funding exclusively through extra services have failed
and have not produced nearly as much funds as the licensing business.

> From the countless local developers in the Silicon Valley area we have
> communicated with, Qt is not typically viewed as a community project.
> There is nothing inherently wrong with this approach, it just did not
> fit our paradigm.

You have to qualify what you mean by "community project". As long as you do
that, it should be no problem.

> We are speaking at CPPCon in September and our intent is simply to
> explain the CLA did not work for us. The main purpose of our
> presentation is to present CopperSpice and offer C++ developers an
> alternative GUI library.

That's fine. We just ask that you don't say "CLA means not a community
project". There are quite a few people and companies that don't like CLAs (I
work for one -- getting Intel to sign the Qt Project CLA took 8 months). Their
existence is an understandable reason to not contribute to a project.

But please don't say we're not a community.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Giuseppe D'Angelo]

Il 21/07/2015 20:37, Thiago Macieira ha scritto:
> As opposed to qMapLessThanKey? Do you mean two QMap with the same key could
> have different comparators?

Why not? Suppose you want to have maps sorting by different criteria,
especially if the type doesn't have proper semantics for operator< and
thus shouldn't have one defined (e.g. complex numbers).

Too bad that adding a template parameter to QMap is a huge SiC, as
people forward declare it with two template arguments, and we never
provided headers for forward declarations... :(

Cheers,
--
Giuseppe D'Angelo | ***@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK [phone]
KDAB - The Qt Experts

[Marc Mutz]

On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
> Il 21/07/2015 20:37, Thiago Macieira ha scritto:
> > As opposed to qMapLessThanKey? Do you mean two QMap with the same key
> > could have different comparators?
>
> Why not? Suppose you want to have maps sorting by different criteria,
> especially if the type doesn't have proper semantics for operator< and
> thus shouldn't have one defined (e.g. complex numbers).
>
> Too bad that adding a template parameter to QMap is a huge SiC, as
> people forward declare it with two template arguments, and we never
> provided headers for forward declarations... :(

It's spelled _s_t_d_:_:_m_a_p_ :)

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Thiago Macieira]

On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
> Il 21/07/2015 20:37, Thiago Macieira ha scritto:
> > As opposed to qMapLessThanKey? Do you mean two QMap with the same key
> > could
> > have different comparators?
>
> Why not?

Not passing judgement. I was only asking for clarification, since that was the
only feature that Ansel mentioned and, depending on the actual change, is not
a feature at all since QMap alreaydy supported it.

> Too bad that adding a template parameter to QMap is a huge SiC, as
> people forward declare it with two template arguments, and we never
> provided headers for forward declarations... :(

We can fix that with C++11 template aliases.

template <typename Key, typename T>
using QMap<Key, T> = QMapComparator<Key, T, qMapLessThanKey<Key>>;

Note however that a function taking QMap<Foo, Bar> is *not* the same as a
function taking QMapComparator<Foo, Bar, qMapLessThanKey<Foo>>. The two types
are not the same, even though they are.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 7/21/15 4:03 PM, Thiago Macieira wrote:
> On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
>> Il 21/07/2015 20:37, Thiago Macieira ha scritto:
>>> As opposed to qMapLessThanKey? Do you mean two QMap with the same key
>>> could
>>> have different comparators?
>> Why not?
> Not passing judgement. I was only asking for clarification, since that was the
> only feature that Ansel mentioned and, depending on the actual change, is not
> a feature at all since QMap alreaydy supported it.
We brought this change up as representative of the kind of things that
are being done. For a more comprehensive list check out the overview
documentation on our website:

http://www.copperspice.com/docs/cs_overview/index.html

Ansel Sermersheim

[Olivier Goffart]

On Tuesday 21. July 2015 16:03:56 Thiago Macieira wrote:
> On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote:
> > Il 21/07/2015 20:37, Thiago Macieira ha scritto:
> > > As opposed to qMapLessThanKey? Do you mean two QMap with the same key
> > > could
> > > have different comparators?
> >
> > Why not?
>
> Not passing judgement. I was only asking for clarification, since that was
> the only feature that Ansel mentioned and, depending on the actual change,
> is not a feature at all since QMap alreaydy supported it.
>
> > Too bad that adding a template parameter to QMap is a huge SiC, as
> > people forward declare it with two template arguments, and we never
> > provided headers for forward declarations... :(
>
> We can fix that with C++11 template aliases.
>
> template <typename Key, typename T>
> using QMap<Key, T> = QMapComparator<Key, T, qMapLessThanKey<Key>>;

This is still source incompatible (because of forward declarations) and binary
incompatible too.

>
> Note however that a function taking QMap<Foo, Bar> is *not* the same as a
> function taking QMapComparator<Foo, Bar, qMapLessThanKey<Foo>>. The two
> types are not the same, even though they are.


Anyway, If one need to do advanced usages, one could use std::map.
Re-implementing the standard library is not a goal of Qt.

[Thiago Macieira]

On Wednesday 22 July 2015 16:47:21 Olivier Goffart wrote:
> > template <typename Key, typename T>
> > using QMap<Key, T> = QMapComparator<Key, T, qMapLessThanKey<Key>>;
>
> This is still source incompatible (because of forward declarations) and
> binary incompatible too.

Oops! You're right.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 7/21/15 11:37 AM, Thiago Macieira wrote:
> On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote:
>> We would like to announce our release of CopperSpice 1.1.0. We have
>> added and changed several things including a modification to to QMap to
>> user defined comparisons.
> As opposed to qMapLessThanKey? Do you mean two QMap with the same key could
> have different comparators?

The qMapLessThanKey solution does not help at all if you want to create
a user defined sort order for a class that already has a defined ordering.

The most common use case of this is creating a QMap<QString, X> that is
sorted case insensitively. The STL allows this for std::map, and coming
to Qt from a background of standard C++ I was amazed that this very
common use case was not supported.

Ansel Sermersheim

[Thiago Macieira]

On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
> The most common use case of this is creating a QMap<QString, X> that is
> sorted case insensitively. The STL allows this for std::map, and coming
> to Qt from a background of standard C++ I was amazed that this very
> common use case was not supported.

Right, we usually work around this by having QMap<CaseInsensitiveString, X>.

This is something we should fix or 6.0, if we can accept the source
compatibility break against forward declarations of QMap.

I don't see the need to do the same for QHash. How often do people need a
different comparator and/or a different hashing function for a given class type?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ansel Sermersheim]

On 7/21/15 6:23 PM, Thiago Macieira wrote:
> On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
>> The most common use case of this is creating a QMap<QString, X> that is
>> sorted case insensitively. The STL allows this for std::map, and coming
>> to Qt from a background of standard C++ I was amazed that this very
>> common use case was not supported.
> Right, we usually work around this by having QMap<CaseInsensitiveString, X>.

Certainly possible to do, but sometimes quite awkward depending on the
situation.

> This is something we should fix or 6.0, if we can accept the source
> compatibility break against forward declarations of QMap.
>
> I don't see the need to do the same for QHash. How often do people need a
> different comparator and/or a different hashing function for a given class type?

I have in the past used non-standard hashing and equality functions for
std::unordered_map, but I will admit it is far less common.

Ansel Sermersheim

[Thiago Macieira]

On Tuesday 21 July 2015 18:32:09 Ansel Sermersheim wrote:
> On 7/21/15 6:23 PM, Thiago Macieira wrote:
> > Right, we usually work around this by having QMap<CaseInsensitiveString,
> > X>.
> Certainly possible to do, but sometimes quite awkward depending on the
> situation.

Agreed.

> > I don't see the need to do the same for QHash. How often do people need a
> > different comparator and/or a different hashing function for a given class
> > type?
> I have in the past used non-standard hashing and equality functions for
> std::unordered_map, but I will admit it is far less common.

Can you share why you needed that?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well
>
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

https://codereview.qt-project.org/115267

I've updated the 5.5.0 changelog to reflect this discussion.

By effect of requiring Clang 3.2 for the C++11 features, we also require XCode
5.0, which in turn removes OS X 10.7 support from 5.7.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Olivier Goffart]

On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well
>
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

+1

There is another point we need to decide on (for Qt 5.7), is whether or not we
relax the policy not to use the standard library in our ABI.

Can we have function that takes or return std::function, std::tuple,
std::unique_ptr, std::vector?

Currently we don't allow it, and this makes it possible to change the
underlying standard library without breaking binary compatibility. (Qt can
link to one standard library, and the application to another. Or, if they use
inline namespace, the namespace can change provided that both old and new
symbols are still in the library.)

However, it is questionable if even this works. We already rely on the
standard library ABI in QException. And most users will have to recompile
everything if they want to change standard library anyway.

We currently do not have a general purpose std::function (there is
QtPrivate::QSlotObjectBase, but it is not as good as std::function
implementations).
I believe it is better to use std::function than trying to reinvent our own.

So should we allow standard library types in our ABI?
Nobody seemed to be opposed in the "Notes from Modern C++ session" thread.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

[Thiago Macieira]

On Friday 26 June 2015 11:59:11 Olivier Goffart wrote:
> However, it is questionable if even this works. We already rely on the
> standard library ABI in QException. And most users will have to recompile
> everything if they want to change standard library anyway.

std::exception is compatible between libc++ and libstdc++, so that doesn't
count.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Olivier Goffart]

On Friday 26. June 2015 08:41:11 Thiago Macieira wrote:
> On Friday 26 June 2015 11:59:11 Olivier Goffart wrote:
> > However, it is questionable if even this works. We already rely on the
> > standard library ABI in QException. And most users will have to recompile
> > everything if they want to change standard library anyway.
>
> std::exception is compatible between libc++ and libstdc++, so that doesn't
> count.

Ok. (But by luck... another version might not)

Anyway, you did not answer the actual question. Are you against changing the
policy or not?


--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

[Thiago Macieira]

On Tuesday 30 June 2015 18:16:34 Olivier Goffart wrote:
> On Friday 26. June 2015 08:41:11 Thiago Macieira wrote:
> > On Friday 26 June 2015 11:59:11 Olivier Goffart wrote:
> > > However, it is questionable if even this works. We already rely on the
> > > standard library ABI in QException. And most users will have to
> > > recompile
> > > everything if they want to change standard library anyway.
> >
> > std::exception is compatible between libc++ and libstdc++, so that doesn't
> > count.
>
> Ok. (But by luck... another version might not)

s/luck/design/

> Anyway, you did not answer the actual question. Are you against changing the
> policy or not?

I am, for several reasons.

For the container types, please use the Qt ones, for API consistency and
familiarity. I don't want to see API using std::vector, period.

Since we're talking about *ABI*, it stands to reason we're talking about
mandatory features, so outside of any #ifdefs that may change between Qt's
build and the user application's. That means any such feature depending on a
C++11 library feature should be protected by a configure-time check and a
#define in qconfig.h. Given our horrible configure script and configure.exe source
code, writing such checks are difficult and time-consuming. More likely than
not, we'll get it wrong.

And finally, I am against it because libc++ and libstdc++ co-existence is still
a goal, even on OS X.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Sune Vuorela]

On 2015-06-26, Olivier Goffart <***@woboq.com> wrote:
> Can we have function that takes or return std::function, std::tuple,
> std::unique_ptr, std::vector?

While I can see the advantage of std::function, I'm not sure why we
would use the remaining ones in API ?

Thiago already mentioned that he didn't like std::vector.
I think we mostly avoid QPair in api's (because it is generally not very
documenting in API). I don't see why std::tuple is any different.

/Sune

[Thiago Macieira]

On Wednesday 01 July 2015 21:03:21 Sune Vuorela wrote:
> I think we mostly avoid QPair in api's (because it is generally not very
> documenting in API). I don't see why std::tuple is any different.

I agree with Sune here. Please create your struct with the types in question
and proper names.

And that's only for very simple structs. Anything more complex should get a d
pointer[*] and become a value-type class. Examples: QNetworkAddressEntry,
QNetworkCookie, etc.

[*] getting a d pointer does not mean getting rid of the private members. See
the Qt 6 task for QDateTime, for example. It's also possible to have classes
with no d pointer, but you need to be absolutely sure there's no chance of
extension for the next 10 years.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Marc Mutz]

On Thursday 02 July 2015 03:02:51 Thiago Macieira wrote:
> [*] getting a d pointer does not mean getting rid of the private members.
> See the Qt 6 task for QDateTime, for example. It's also possible to have
> classes with no d pointer, but you need to be absolutely sure there's no
> chance of extension for the next 10 years.

I would qualify it as "add a d-pointer if you envision further extensions that
you could implement now but choose not to." Even so, always keep in mind that
you can always create a new type instead of extending an existing one.

Taking QColor as an example, it would have been perfectly ok (and even better
design, imo) to start with QColorRGB8 and QColorHSV8, and when HSL support is
added, make a new QColorHSL8, and with 16-bit support, add -16 classes.
There's a reason QColor isn't used in low-level API (instead, QRgb is used),
and that is its complexity (just look at op== if you don't believe).

HSL or 16-bit support can anyway not be used by an app without active code
changes, and thus a recompile. And if you want a color type as a black-box
pass-through, you can use QVariant, or a more specialised QAnyColor.

IMO, d-pointers should be added to polymorphic classes, because by their very
nature, they can receive updates to behaviour without a user having to
recompile. And else to value classes where you know there will be updates in
the future, and having a separate class for it is not an option.

D-pointers are not called Compiler Firewalls for nothing. Just compare
assembly generated from use of QColor (which doesn't even have a d-pointer,
but is mostly out-of-line anyway) with that generated for QRgb.

For QColor, the optimiser is all but disabled.

And this stuff matters. No-one is using C++ to get the performance they can
have with Java or C#. And one of the advantages of C++ is that user-defined
types can enjoy the performance of built-in types, and don't have to _be_ a
compiler firewall.

We have erred too much on the side of the d-pointer, in the past. We should be
more conscious of its negative effects.

At the same time, we have been very bad at creating small classes. Maybe
because reviews would blindly ask for a d-pointer, then? I don't know. Those
we have are pretty good, don't get me wrong. We just have too little of them.
QGradientStop is a QPair<qreal,QColor>. That's just lazy. It should be a
struct { qreal step; QColor color }, or, maybe, because Q*Animation classes
have the same need, a more generically-named { step, value }, so one can
easily write them as templates:

template <typename Value>
struct QStop {
qreal step;
Value value;
};
using QGradientStop = QStop<QColor>;
using QGraphicsItemAnimation::PositionStop = QStop<QPointF>;
...

Nothing of the above contradicts Thiago in any way. It's just Qt's historic
bias to lots of pimpls that I'd like to shift.

Thanks,
Marc

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Thiago Macieira]

On Thursday 02 July 2015 10:44:14 Marc Mutz wrote:
> D-pointers are not called Compiler Firewalls for nothing. Just compare
> assembly generated from use of QColor (which doesn't even have a d-pointer,
> but is mostly out-of-line anyway) with that generated for QRgb.

That's not a fair comparison. QRgb is not a class, it's a typedef to unsigned
int.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Marc Mutz]

On Thursday 02 July 2015 17:48:59 Thiago Macieira wrote:
> On Thursday 02 July 2015 10:44:14 Marc Mutz wrote:
> > D-pointers are not called Compiler Firewalls for nothing. Just compare
> > assembly generated from use of QColor (which doesn't even have a
> > d-pointer, but is mostly out-of-line anyway) with that generated for
> > QRgb.
>
> That's not a fair comparison. QRgb is not a class, it's a typedef to
> unsigned int.

It's equivalent to what a fully inline QColorRGB(A)8 should compile to, modulo
compiler bugs.

If you don't like the comparision to QRgb, s/QRgb/QRgba64/, which _is_ a
class.

Thanks,
Marc

--
Marc Mutz <***@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: [phone]
KDAB - The Qt Experts

[Thiago Macieira]

On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally

BTW, there's one more C++11 feature I'd like to use unconditionally starting
in Qt 5.7: atomics. They've been supported since Clang 3.1, ICC 13.0, GCC 4.7,
MSVC 2012.

This is needed because our assembly apparently has problems, as in QTBUG-46949
(see especially
https://bugreports.qt.io/browse/QTBUG-46949?focusedCommentId=285873#comment-285873
). I don't want to maintain non-x86 assembly anymore.

So here's the plan:
* Qt 5.6: will use std::atomic, if available
* Qt 5.7: will use std::atomic unconditionally

In any case, this is a net improvement:

Arch Qt assembly GCC 4.9 atomics
All all are lock-free all sizes are supported
ARMv5 4-byte only, Linux-only out-of-line, lock-free on Linux
ARMv6 4-byte only 4-byte inline, others out-of-line
ARMv7A, v7M, v8 all sizes all sizes inline and lock-free
IA-64 all sizes all sizes inline and lock-free
MIPS32 4-byte only 1 through 4 bytes inline
MIPS64 4- and 8-bytes only all sizes inline and lock-free
x86 1-4 bytes only all sizes inline and lock-free
x86-64 all sizes all sizes inline and lock-free

There is no case where the Qt inline, lock-free assembly would be replaced by
non-lock-free code. On ARMv5, there's a slight drop in performance as the
inline assembly is replaced by an out-of-line function call, that's all.

Any architecture not listed above (notably AArch64) is only supported by
qatomic_cxx11.h and qatomic_gcc.h, so either this is a no-op for them, or net
improvement by supporting more sizes and not doing a full barrier.

I've only tested with GCC 4.9. I'm pretty sure support in GCC 4.8 is the same.
However, GCC 4.7 is not very good at atomics anywhere except on x86. I don't
care. You can easily upgrade to 4.8 to get better (non-full barrier for
everything) performance.

The only compiler I currently know that will have problems with this is the
Intel compiler on OS X when using libc++ older than Subversion r215305.
Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that
change. To restore functionality, I will revert
1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
> So here's the plan:
> * Qt 5.6: will use std::atomic, if available
> * Qt 5.7: will use std::atomic unconditionally

Well, first snag: MSVC has no support for constexpr, so it won't work.

The above should read then:
* Qt 5.7: will use std::atomic unconditionally, except with MSVC

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Wednesday 08 July 2015 14:53:23 Thiago Macieira wrote:
> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
> > So here's the plan:
> > * Qt 5.6: will use std::atomic, if available
> > * Qt 5.7: will use std::atomic unconditionally
>
> Well, first snag: MSVC has no support for constexpr, so it won't work.
>
> The above should read then:
> * Qt 5.7: will use std::atomic unconditionally, except with MSVC

Done. The 5.7 commit is available for comment:

https://codereview.qt-project.org/121144
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
> The only compiler I currently know that will have problems with this is the
> Intel compiler on OS X when using libc++ older than Subversion r215305.
> Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that
> change. To restore functionality, I will revert
> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.

Upon further investigation, it turns out that ICC has worked around the libc++
problem since version 15.0 by providing its own std::atomic implementation
when __clang__ is defined (probably a mistake and should have been a check for
_LIBCPP_VERSION).

However, its implementation is broken. I've just reported two bugs against
version 16.0 beta. One bug can be easily worked around[1] but the other[2]
isn't easy. I've made sure to report that one as a Critical issue, so let's
hope there's an update released, fixing the issue, before 5.7 is out.

[1] Issue id 6000117277: std::atomic's constructor is missing "constexpr".
Note how libc++'s outside of Clang is too
(https://llvm.org/bugs/show_bug.cgi?id=24114)

[2] Issue id 6000117300: std::atomic<function_pointer> and std::atomic<const
T*> fail to compile. Can be fixed by a one-line change, casting to (void*). We
hit both cases in QtCore:

qlogging.cpp: static QBasicAtomicPointer<void (QtMsgType, const char*)>
msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler);

qobject_p.h: QAtomicPointer<const int> argumentTypes;

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Monday 13 July 2015 18:44:40 Thiago Macieira wrote:
> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
> > The only compiler I currently know that will have problems with this is
> > the Intel compiler on OS X when using libc++ older than Subversion
> > r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way
> > before that change. To restore functionality, I will revert
> > 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.
>
> Upon further investigation, it turns out that ICC has worked around the
> libc++ problem since version 15.0 by providing its own std::atomic
> implementation when __clang__ is defined (probably a mistake and should
> have been a check for _LIBCPP_VERSION).

Looks like std::atomic that came with the latest XCode that still runs on OS X
10.8 is also broken with Clang.

Choices:
1) drop the ability to build Qt and applications using an old XCode
2) keep qatomic_x86.h for OS X.

So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should
not affect using it as a target.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Jake Petroules]

> On Aug 17, 2015, at 10:46 PM, Thiago Macieira <***@intel.com> wrote:
>
> On Monday 13 July 2015 18:44:40 Thiago Macieira wrote:
>> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
>>> The only compiler I currently know that will have problems with this is
>>> the Intel compiler on OS X when using libc++ older than Subversion
>>> r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way
>>> before that change. To restore functionality, I will revert
>>> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.
>>
>> Upon further investigation, it turns out that ICC has worked around the
>> libc++ problem since version 15.0 by providing its own std::atomic
>> implementation when __clang__ is defined (probably a mistake and should
>> have been a check for _LIBCPP_VERSION).
>
> Looks like std::atomic that came with the latest XCode that still runs on OS X
> 10.8 is also broken with Clang.
>
> Choices:
> 1) drop the ability to build Qt and applications using an old XCode
> 2) keep qatomic_x86.h for OS X.
>
> So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should
> not affect using it as a target.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


I haven't a clue why people would bother using old OS X platforms for development, *especially* now that they don't charge for it. Plus I think submitting to app stores requires the latest Xcode anyways so there's another point against it.
--
Jake Petroules - jake.petroules at petroules.com

[Thiago Macieira]

On Monday 17 August 2015 23:25:05 Jake Petroules wrote:
> I haven't a clue why people would bother using old OS X platforms for
> development, *especially* now that they don't charge for it. Plus I think
> submitting to app stores requires the latest Xcode anyways so there's
> another point against it.

Right. In the past, the thinking was that people wouldn't upgrade because it
would require them to pay for it. That reason is now gone.

They may still complain if the newer versions of OS X no longer run on some
older hardware. But isn't it true that all 64-bit capable Intel Mac can run
the latest OS X? Or is there any hardware that would have upgraded to 10.8 but
not further?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Ziller Eike]

> On Aug 18, 2015, at 08:49, Thiago Macieira <***@intel.com> wrote:
>
> On Monday 17 August 2015 23:25:05 Jake Petroules wrote:
>> I haven't a clue why people would bother using old OS X platforms for
>> development, *especially* now that they don't charge for it. Plus I think
>> submitting to app stores requires the latest Xcode anyways so there's
>> another point against it.
>
> Right. In the past, the thinking was that people wouldn't upgrade because it
> would require them to pay for it. That reason is now gone.
>
> They may still complain if the newer versions of OS X no longer run on some
> older hardware. But isn't it true that all 64-bit capable Intel Mac can run
> the latest OS X? Or is there any hardware that would have upgraded to 10.8 but
> not further?

10.9 did not increase hardware requirements:

10.8: https://support.apple.com/en-us/HT202575
10.9: https://support.apple.com/en-us/HT201364

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

[Sorvig Morten]

> On 18 Aug 2015, at 07:46, Thiago Macieira <***@intel.com> wrote:
>
> On Monday 13 July 2015 18:44:40 Thiago Macieira wrote:
>> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
>>> The only compiler I currently know that will have problems with this is
>>> the Intel compiler on OS X when using libc++ older than Subversion
>>> r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way
>>> before that change. To restore functionality, I will revert
>>> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.
>>
>> Upon further investigation, it turns out that ICC has worked around the
>> libc++ problem since version 15.0 by providing its own std::atomic
>> implementation when __clang__ is defined (probably a mistake and should
>> have been a check for _LIBCPP_VERSION).
>
> Looks like std::atomic that came with the latest XCode that still runs on OS X
> 10.8 is also broken with Clang.
>
> Choices:
> 1) drop the ability to build Qt and applications using an old XCode
> 2) keep qatomic_x86.h for OS X.
>
> So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should
> not affect using it as a target.

CI testing may be sufficient reason to keep Qt building on 10.8, unless we have/gain the the capability to have separate “build” and “test” machines.

Morten

[Knoll Lars]

On 18/08/15 09:56, "development-bounces+lars.knoll=***@qt-project.org on behalf of Sorvig Morten" <development-bounces+lars.knoll=***@qt-project.org on behalf of ***@theqtcompany.com> wrote:



>
>> On 18 Aug 2015, at 07:46, Thiago Macieira <***@intel.com> wrote:
>>
>> On Monday 13 July 2015 18:44:40 Thiago Macieira wrote:
>>> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
>>>> The only compiler I currently know that will have problems with this is
>>>> the Intel compiler on OS X when using libc++ older than Subversion
>>>> r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way
>>>> before that change. To restore functionality, I will revert
>>>> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev.
>>>
>>> Upon further investigation, it turns out that ICC has worked around the
>>> libc++ problem since version 15.0 by providing its own std::atomic
>>> implementation when __clang__ is defined (probably a mistake and should
>>> have been a check for _LIBCPP_VERSION).
>>
>> Looks like std::atomic that came with the latest XCode that still runs on OS X
>> 10.8 is also broken with Clang.
>>
>> Choices:
>> 1) drop the ability to build Qt and applications using an old XCode
>> 2) keep qatomic_x86.h for OS X.
>>
>> So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should
>> not affect using it as a target.
>
>CI testing may be sufficient reason to keep Qt building on 10.8, unless we have/gain the the capability to have separate “build” and “test” machines.

Longer term, we could add that capability, but we don't have it yet, and the focus for the CI is on other, more important items currently.

I'd say we keep it building on 10.8 for now, and use qatomic_x86. IIRC the file was anyway still being used by at least one other platform.

Cheers,
Lars

[Thiago Macieira]

On Tuesday 18 August 2015 07:56:24 Sorvig Morten wrote:
> > Choices:
> > 1) drop the ability to build Qt and applications using an old XCode
> > 2) keep qatomic_x86.h for OS X.
> >
> >
> >
> > So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This
> > should not affect using it as a target.
>
> CI testing may be sufficient reason to keep Qt building on 10.8, unless we
> have/gain the the capability to have separate “build” and “test” machines.

That's a good point.

Anyway, the build error is weird, since there's no reason for the problems to
start happening in the commit they're happening. Either they were already
there and nothing should be compiling, or they shouldn't be showing up.

I'll try to modify tst_qatomicinteger to see if it helps.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well

Another thing: we should turn on C++11 support by default for user
applications as of 5.6.

You can undo this by:

CONFIG -= c++11

You can add this now to your code.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Wednesday 08 July 2015 13:43:16 Thiago Macieira wrote:
> On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> > Qt 5.6:
> >
> > * We make 5.6 a long term supported release
> > * We still support C++98 compilers in this release (for the last time),
> > i.e. We keep the 5.5 compiler baseline
> > * WEC7 will be still supported
> > * QNX 6.5 is not supported anymore
> > * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> > the sources compile against 5.6)
> > * We keep Qt Script for this release, it’ll be gone in 5.7 as well
>
> Another thing: we should turn on C++11 support by default for user
> applications as of 5.6.
>
> You can undo this by:
>
> CONFIG -= c++11
>
> You can add this now to your code.

https://codereview.qt-project.org/121023
https://codereview.qt-project.org/121022

I was nice made -std=gnu++11 the default instead of -std=c++11 :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> * Qt Quick1 and Qt WebKit are not part of the release (but we test that
> the sources compile against 5.6)
> * We keep Qt Script for this release, it’ll be gone in 5.7 as well

Summary of changes:

https://codereview.qt-project.org/121026 C++11 default in user applications
https://codereview.qt-project.org/121141 Enable C++14 or C++1z in Qt itself
https://codereview.qt-project.org/121142 Drop QNX 6.5 and libstdc++/OS X
https://codereview.qt-project.org/121145 Remove macx-g++* mkspecs

> Qt 5.7:
>
> * New compiler baseline with gcc 4.7 and VC++ 2012
> * Enable and use the C++11 features supported by these compilers
> unconditionally
> * WEC7 not supported anymore, WEC2013 supported
> * Probably remove support for older Android, Mac and Linux versions as
> well (to be discussed)

https://codereview.qt-project.org/121144 Require C++11 atomics (except MSVC)
https://codereview.qt-project.org/121146 Remove support for MSVC < 2012
https://codereview.qt-project.org/121147 Remove -no-c++11 option
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center