Re: [Development] Qt LTS & C++11 plans

[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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS & C++11 plans

[Sune Vuorela]

On 2015-06-26, Olivier Goffart  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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Thiago Macieira]

On Wednesday 01 July 2015 18:55:24 Oswald Buddenhagen wrote:
> > My Chicago based sales rep told me that ( somewhere buried in my license
> > fine print ) I could not release software using unreleased versions of Qt
> > Enterprise.>
> > 
> 
> that makes sense for feature releases, but not for bugfixes. otherwise,
> qt support wouldn't be able to supply you with fixes, either, as these
> obviously create "unreleased versions of qt", too.

Indeed.

But to put your mind at ease, you can just apply this patch and it won't get 
you the other unreleased changes:

https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=patch;h=7d5e849e2808e9051a6d3ab19f29109b852f7bc9

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Oswald Buddenhagen]

On Wed, Jul 01, 2015 at 04:36:02PM +, Edward Sutton wrote:
> >>Is there a work-around I could use in my Qt project file?
> 
> >Upgrade to 5.5.1. It's already fixed.
> 
> >The problem was not deemed important enough to affect the 5.5.0 release.
> 
> 
> My Chicago based sales rep told me that ( somewhere buried in my license fine 
> print ) I could not release software using unreleased versions of Qt 
> Enterprise.
> 
that makes sense for feature releases, but not for bugfixes. otherwise,
qt support wouldn't be able to supply you with fixes, either, as these
obviously create "unreleased versions of qt", too.

> Lawyers frighten me much more than chief architects. :-)
> 
lawyers still put their pants on one leg at a time.

IANAL, YMMV, blah blah blah

> -Ed
> 
> 
> 
> 
> 
> On Jul 1, 2015, at 10:19 AM, Thiago Macieira 
> mailto:thiago.macie...@intel.com>> wrote:
> 
> On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote:
> Is there a work-around I could use in my Qt project file?
> 
> Upgrade to 5.5.1. It's already fixed.
> 
> The problem was not deemed important enough to affect the 5.5.0 release.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> This email and any files transmitted with it from The Charles Machine Works, 
> Inc. are confidential and intended solely for the use of the individual or 
> entity to which they are addressed. If you have received this email in error 
> please notify the sender. Our company accepts no liability for the contents 
> of this email, or for the consequences of any actions taken on the basis of 
> the information provided, unless that information is subsequently confirmed 
> in writing. Please note that any views or opinions presented in this email 
> are solely those of the author and do not necessarily represent those of the 
> company. Finally, the recipient should check this email and any attachments 
> for the presence of viruses. The company accepts no liability for any damage 
> caused by any virus transmitted by this email.

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Edward Sutton]

>>Is there a work-around I could use in my Qt project file?

>Upgrade to 5.5.1. It's already fixed.

>The problem was not deemed important enough to affect the 5.5.0 release.


My Chicago based sales rep told me that ( somewhere buried in my license fine 
print ) I could not release software using unreleased versions of Qt Enterprise.


Lawyers frighten me much more than chief architects. :-)

-Ed





On Jul 1, 2015, at 10:19 AM, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote:
Is there a work-around I could use in my Qt project file?

Upgrade to 5.5.1. It's already fixed.

The problem was not deemed important enough to affect the 5.5.0 release.
--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Konstantin Tokarev]

30.06.2015, 23:38, "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!

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

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

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Thiago Macieira]

On Wednesday 01 July 2015 15:15:19 Edward Sutton wrote:
> Is there a work-around I could use in my Qt project file?

Upgrade to 5.5.1. It's already fixed.

The problem was not deemed important enough to affect the 5.5.0 release.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] std:: in Qt ABI (was: Qt LTS & C++11 plans)

[Thiago Macieira]

On Wednesday 01 July 2015 07:20:18 Koehne Kai wrote:
> What I think would be very helpful is std::function though. We've a couple
> of places where we take function pointers with its awkward design and
> limitations. In others we start to have classes with just one virtual
> member ... This is all much more elegantly solved by just taking a
> std::function.

That is true, no doubt about it.

> > 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
> > C++a  #define in qconfig.h
> 
> I guess this is only a limit until we require C++11 (planned for Qt 5.7)?

We're not requiring all of C++11 and we only discussed core language features. 
We did not discuss standard library features at all, especially since we have 
no data on what got supported and when, including when vendors replace the 
library with a third-party implementations (Dinkumware in QNX, for example).

Even looking at just libstdc++, we cannot be sure that the library headers 
match the GCC version being used, as it could be older. There's no 
monotonically-increasing macro that indicates its version number...

I'd rather SG-10 had standardised all the features we need in SD-6, but the 
__cpp_lib_xxx macros are quite limited. There's none for std::function, for 
example.

Even worse, we're talking about ABI here, so there needs to be no change due 
to a compiler or standard library update. So, no, standard library feature 
usages require a configure check and a macro in qconfig.h.

Good luck writing such tests.

> > 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.
> 
> My understanding is that most (all?) Linux distributions focus on  libc++.
> On OS X it's libstdc++.

The opposite, like your other email says.

That is true. And like I posted before, there doesn't seem to be any Linux 
distribution that builds libc++ correctly so that it can actually share ABI 
with libstdc++.

That leaves OS X and the BSDs. My point is that it's still a goal, even on 
OS X. The same way that some people still use 32-bit builds on OS X because 
they need to link to a proprietary module only provided in 32-bit, it's 
possible that such proprietary modules are linked to and require use of 
libstdc++. Therefore, if we used libc++ in our own ABI, such users would have 
to put up a firewall between the two modules.

It's hard to quantify how difficult that would be, though. It's a lot easier 
than the 32-bit vs 64-bit case, so maybe we shouldn't consider it a problem.

But my opinion stands that we should leave as-is and not require the ABI.

> An ABI incompatibility in Qt would affect only apps that
> - don't compile Qt themselves, but use the prebuilt ones (from distribution,
> or from binary installers) - link against 'the other' C++ runtime library
> themselves, or link against libraries that do so

The 5.5.0 changelog states that builds on OS X with libstdc++ are deprecated 
and will be removed for 5.7. That did not apply to the application code 
itself, which is the discussion here.

If we remove the ability of the application code to use a different C library 
than Qt itself, then we effectively remove everyone's ability of using 
libstdc++ on OS X, short of putting up the firewall like I described.

> I'm wondering how big the use case really is. In the worst case we can also
> provide different builds ourselves (Not that I want to pitch this, but we
> do the stunt on Windows already).

I don't know how big it is either. It probably happens as often as the need 
for 32-bit on OS X, though the solutions could be different.

Does anyone know how often 32-bit on OS X is required?

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Edward Sutton]

Same issue here.

I had to modify qobjectdefs.h to define Q_OBJECT_NO_OVERRIDE_WARNING to nothing.


#if defined(Q_CC_CLANG) && Q_CC_CLANG >= 306

//#  define Q_OBJECT_NO_OVERRIDE_WARNING  
QT_WARNING_DISABLE_CLANG("-Winconsistent-missing-override”)

#  define Q_OBJECT_NO_OVERRIDE_WARNING

#else

#  define Q_OBJECT_NO_OVERRIDE_WARNING

#endif

Is there a work-around I could use in my Qt project file?

-Ed

Qt 5.5.0 release
iOS & OS X
Command Line Tools (OS X 10.10) 6.4.


On Jul 1, 2015, at 9:50 AM, Stephen Kelly 
mailto:steve...@gmail.com>> wrote:

Hello,

I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
many warnings for each translation unit about
-Winconsistent-missing-override.

In file included from
/Users/ske/dev/src/qt55/qtdeclarative/src/qml/debugger/qqmldebugserver.cpp:34:
In file included from
/Users/ske/dev/src/qt55/qtdeclarative/src/qml/debugger/qqmldebugserver_p.h:39:
In file included from
../../include/QtQml/5.5.0/QtQml/private/qqmldebugservice_p.h:1:
../../include/QtQml/5.5.0/QtQml/private/../../../../../../src/qml/debugger/qqmldebugservice_p.h:60:5:
warning: unknown warning group '-Winconsistent-missing-override',
ignored [-Wunknown-pragmas]
   Q_OBJECT
   ^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qobjectdefs.h:156:5:
note: expanded from macro 'Q_OBJECT'
   Q_OBJECT_NO_OVERRIDE_WARNING \
   ^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qobjectdefs.h:146:45:
note: expanded from macro 'Q_OBJECT_NO_OVERRIDE_WARNING'
£  define Q_OBJECT_NO_OVERRIDE_WARNING
QT_WARNING_DISABLE_CLANG("-Winconsistent-missing-override")
   ^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qcompilerdetection.h:1125:49:
note: expanded from macro 'QT_WARNING_DISABLE_CLANG'
£  define QT_WARNING_DISABLE_CLANG(text)QT_DO_PRAGMA(clang
diagnostic ignored text)
   ^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qcompilerdetection.h:1096:49:
note: expanded from macro 'QT_DO_PRAGMA'
£define QT_DO_PRAGMA(text)  _Pragma(£text)
   ^

:23:27: note: expanded from here
clang diagnostic ignored "-Winconsistent-missing-override"
 ^

I see qtbase commit v5.5.0-alpha1~786 (Fix Clang warning about
inconsistent use of C++11 override, 2014-12-18). It attempts to affect
'Q_CC_CLANG >= 306'. Do the Qt macros know the difference between
'clang' and 'apple clang'? All version checks of 'clang'-based
compilers must be aware of the difference and check both compilers.

Thanks,

Steve.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Olivier Goffart]

On Wednesday 1. July 2015 16:50:09 Stephen Kelly wrote:
> Hello,
> 
> I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
> many warnings for each translation unit about
> -Winconsistent-missing-override.

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

It was just too late for Qt 5.5.0 but it will be in 5.5.1


-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] -Winconsistent-missing-override warning with latest Xcode and Qt 5.5

[Stephen Kelly]

Hello,

I just tried building Qt 5.5 with Xcode 6.3.2. It built, but emitted
many warnings for each translation unit about
-Winconsistent-missing-override.

In file included from
/Users/ske/dev/src/qt55/qtdeclarative/src/qml/debugger/qqmldebugserver.cpp:34:
In file included from
/Users/ske/dev/src/qt55/qtdeclarative/src/qml/debugger/qqmldebugserver_p.h:39:
In file included from
../../include/QtQml/5.5.0/QtQml/private/qqmldebugservice_p.h:1:
../../include/QtQml/5.5.0/QtQml/private/../../../../../../src/qml/debugger/qqmldebugservice_p.h:60:5:
warning: unknown warning group '-Winconsistent-missing-override',
ignored [-Wunknown-pragmas]
Q_OBJECT
^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qobjectdefs.h:156:5:
note: expanded from macro 'Q_OBJECT'
Q_OBJECT_NO_OVERRIDE_WARNING \
^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qobjectdefs.h:146:45:
note: expanded from macro 'Q_OBJECT_NO_OVERRIDE_WARNING'
£  define Q_OBJECT_NO_OVERRIDE_WARNING
QT_WARNING_DISABLE_CLANG("-Winconsistent-missing-override")
^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qcompilerdetection.h:1125:49:
note: expanded from macro 'QT_WARNING_DISABLE_CLANG'
£  define QT_WARNING_DISABLE_CLANG(text)QT_DO_PRAGMA(clang
diagnostic ignored text)
^

/Users/ske/dev/prefix55/lib/QtCore.framework/Headers/qcompilerdetection.h:1096:49:
note: expanded from macro 'QT_DO_PRAGMA'
£define QT_DO_PRAGMA(text)  _Pragma(£text)
^

:23:27: note: expanded from here
 clang diagnostic ignored "-Winconsistent-missing-override"
  ^

I see qtbase commit v5.5.0-alpha1~786 (Fix Clang warning about
inconsistent use of C++11 override, 2014-12-18). It attempts to affect
'Q_CC_CLANG >= 306'. Do the Qt macros know the difference between
'clang' and 'apple clang'? All version checks of 'clang'-based
compilers must be aware of the difference and check both compilers.

Thanks,

Steve.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Announce] Qt 5.5 released

[List for announcements regarding Qt releases and development]

Hi,


Qt 5.5 has just been released. For details check the blog post at 
http://blog.qt.io/blog/2015/07/01/qt-5-5-released/ and http://www.qt.io/qt5-5/

Big thanks to everyone involved!

Br,
Akseli
___
Announce mailing list
annou...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] CI problems

[Simon Hausmann]

Hi,

We are currently experiencing severe connectivity issues in our CI 
infrastructure. As a result integrations staged in Gerrit are likely to fail, 
hang or - in the worst case - kill kittens.

Digia IT is working on it.

Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] std:: in Qt ABI (was: Qt LTS & C++11 plans)

[Koehne Kai]

> -Original Message-
> Subject: [Development] std:: in Qt ABI (was: Qt LTS & C++11 plans)

Side note: Outlook decides to not show the first four characters (std:) in the 
Subject line/Compact View, and also drops it when Replying. WTF?

> [...]
> My understanding is that most (all?) Linux distributions focus on  libc++. On 
> OS
> X it's libstdc++.

Obviously it's the other way round. Sorry about this.

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] std:: in Qt ABI (was: Qt LTS & C++11 plans)

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=theqtcompany@qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany@qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: Tuesday, June 30, 2015 10:17 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt LTS & C++11 plans
>
> 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.

Fair enough about the containers. std::string and std::list is also problematic 
because of https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

What I think would be very helpful is std::function though. We've a couple of 
places where we take function pointers with its awkward design and limitations. 
In others we start to have classes with just one virtual member ... This is all 
much more elegantly solved by just taking a std::function.

> 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
> C++a  #define in qconfig.h

I guess this is only a limit until we require C++11 (planned for Qt 5.7)?

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

My understanding is that most (all?) Linux distributions focus on  libc++. On 
OS X it's libstdc++. 

An ABI incompatibility in Qt would affect only apps that
- don't compile Qt themselves, but use the prebuilt ones (from distribution, or 
from binary installers)
- link against 'the other' C++ runtime library themselves, or link against 
libraries that do so

I'm wondering how big the use case really is. In the worst case we can also 
provide different builds ourselves (Not that I want to pitch this, but we do 
the stunt on Windows already).

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development