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

On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > Anyway, i'd like to start the white list with std::enable_if https://codereview.qt-project.org/142782 proposal to add std::hash, too: https://codereview.qt-project.org/142791 -- Marc Mutz | Senior Software

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

On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > > One more thing: I'd like a whitelist of features that have been tested > > and are known to work on all platforms. > > The white list can be obtained by doing 'git grep

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

On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > One more thing: I'd like a whitelist of features that have been tested and > are known to work on all platforms. The white list can be obtained by doing 'git grep "std::"' :-) Anyway, i'd like to start the white list with

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

On Monday 23 November 2015 14:40:38 Marc Mutz wrote: > > The white list can be obtained by doing 'git grep "std::"' :-) > > > > > > > > Anyway, i'd like to start the white list with std::enable_if > > I'd like to add , too. And std::declval<>. > > All of enable_if, declval, and type_traits

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

On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > Fully agree to that. But as long as we can’t execute autotests on all > > platforms in the CI someone will need to manually check those on some of > > the target platforms if

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

On Saturday 14 November 2015 20:42:18 Marc Mutz wrote: > On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > > Fully agree to that. But as long as we can’t execute autotests on all > > > platforms in the CI someone will need

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

On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > Fully agree to that. But as long as we can’t execute autotests on all > platforms in the CI someone will need to manually check those on some of > the target platforms if we extend the set of features used. They can be added to

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

On Tuesday 10 November 2015 20:22:28 Knoll Lars wrote: > At least for now, I don't want us to rely too much on standard library > features in our APIs (ie. Using these types in the APIs we expose to our > users). > > But I am not opposed to using any of these features in our implementation, > if

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

On 11/11/15 00:41, "Development on behalf of Marc Mutz" wrote: >On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: >> Likewise, Marc is trying to use std::declval and type traits >> in exception specification

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

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 By "C++11 features", do you mean only core language feature, or can we also use standard

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

On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Since all of these are C++11 features supported by these compiler, I would > assume that we can use them unconditionally. The problem is that the Standard Library in use is not always the one provided with the compiler. See the cases

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

On 04/11/15 15:31, "Albert Astals Cid" wrote: >On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars > wrote: >> Qt 5.6: >> >> * We make 5.6 a long term supported release > >Any plan on how long will be that "long term"? 2 years? 5 years? 3

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

On 10/11/15 19:43, "Olivier Goffart" wrote: >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 > >By "C++11

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

On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Likewise, Marc is trying to use std::declval and type traits > in exception specification [https://codereview.qt-project.org/140132/] declval is in use for exception specifications since at least 5.5 (in QPair). As for type_traits,

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

On Tuesday 10 November 2015 12:10:17 Thiago Macieira wrote: > The problem is that the Standard Library in use is not always the one > provided with the compiler. See the cases of libstdc++ with Clang and > Dinkumware with QNX's GCC. > > If we're going to use certain Standard Library features that

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

On 18 Aug 2015, at 07:46, Thiago Macieira thiago.macie...@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

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

On Aug 18, 2015, at 08:49, Thiago Macieira thiago.macie...@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

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

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

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

On Aug 17, 2015, at 10:46 PM, Thiago Macieira thiago.macie...@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

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

On 18/08/15 09:56, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Sorvig Morten development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of morten.sor...@theqtcompany.com wrote: On 18 Aug 2015, at 07:46, Thiago Macieira thiago.macie...@intel.com

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

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.

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

On Wednesday 22 July 2015 16:47:21 Olivier Goffart wrote: template typename Key, typename T using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey; This is still source incompatible (because of forward declarations) and binary incompatible too. Oops! You're right. -- Thiago

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

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?

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

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

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

Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@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

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

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 QMapCaseInsensitiveString, X. Certainly possible to do, but sometimes quite awkward depending on the situation. Agreed. I don't see the need

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

On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote: The most common use case of this is creating a QMapQString, 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

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

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

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

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 QMapQString, 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

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

On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote: Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim an...@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

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

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

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

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

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

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

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

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

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

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,

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

On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim an...@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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30.06.2015, 23:38, Bernhard priv...@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

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

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

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

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

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

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

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.

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

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.

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

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

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

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,

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

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 ___ Development mailing list Development@qt-project.org

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

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,

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

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

On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@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

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

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

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

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

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

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

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

On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote: On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@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.

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

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

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

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

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

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

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

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

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

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

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

] 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

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

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

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

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

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

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

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

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote: On 25/06/15 11:43, Teske Daniel daniel.te...@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

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

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars lars.kn...@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

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

:18 PM To: Knoll Lars Cc: development@qt-project.org Subject: Re: [Development] Qt LTS C++11 plans On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars lars.kn...@theqtcompany.commailto:lars.kn...@theqtcompany.com wrote: Well, please tell me where this is such a big problem that we *have to have* VS2013

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

On 25/06/15 12:43, Teske Daniel daniel.te...@theqtcompany.com wrote: On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote: On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote: * WEC7 not supported anymore, WEC2013 supported So what is the time frame for dropping WEC2013?

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

On 25/06/15 11:43, Teske Daniel daniel.te...@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.

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

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

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

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

* 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 ___ Development mailing list Development@qt-project.org

  1   2   >