Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Hi Daniel, On Thu, Feb 19, 2015 at 01:29:48PM +0100, Daniel Teske wrote: > Hi, > > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 > and > C++14 added a lot of new good features. C++17 is planned to be a big step > again. > > Qt needs to evolve together with C++ or it will be a outdated toolkit stuck > in > a C++98 world. Agreed, but there is no free lunch. See below. > > As an example, Qt's container classes and C++11 range based for loop do not > mix very well.[1] And for the same reason, the upcoming Ranges TS will not be > too useful for Qt's container. > > We have started using some parts of C++11 in Creator a year ago and our > experience is that lambdas (and std::function) are useful everywhere. Today > we > have more than 400 lambdas in Creator's source and have several interfaces > that take a std::function. > > I would expect that allowing C++11 in Qt would similarly lead to a wider > understanding on how to leverage the new features for better code and better > APIs. > > We need to start now and deprecate old compilers that do not support any > C++11 > features at all. I I suggest requiring support for lambda as > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all > platforms that do not in Qt 5.6. That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a relatively new release), and BlackBerries. I personally would have loved to remove support for 6.5.0, since it is based on an old gcc version that can barely keep up with latest C++ developments (and keep giving me maintenance headaches from time to time). But strategically (read, comercially) speaking, this is still not possible - QNX 6.5.0 is still widely deployed. The move to 6.6.0 is happening at a slow pace - probably much slower than the time it will take us to reach Qt 5.7. One of the many reasons for that is that many of those systems running QNX are homologated and changing/upgrading involves lots of different process apart from the technical stuff. While I am not for keeping Qt stuck in the last century, I think a more sensible move would be to actually analyze how far we can push it given the current major platforms Qt is being used on, in other words, follow the market, and also take into account the trade-off of dropping platforms that generate revenue in the form of trainings, services, commercial licensing and last but not least, code contributions. I am taking QNX as an example because this is the platform I am familiar with, but I guess this could also affect other platforms such as Windows CE. Just my opinion. Thanks, Rafael -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Daniel Teske schreef op 19-2-2015 om 13:29: > Hi, > > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and > C++14 added a lot of new good features. C++17 is planned to be a big step > again. > > Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in > a C++98 world. > > As an example, Qt's container classes and C++11 range based for loop do not > mix very well.[1] And for the same reason, the upcoming Ranges TS will not be > too useful for Qt's container. > > We have started using some parts of C++11 in Creator a year ago and our > experience is that lambdas (and std::function) are useful everywhere. Today we > have more than 400 lambdas in Creator's source and have several interfaces > that take a std::function. > > I would expect that allowing C++11 in Qt would similarly lead to a wider > understanding on how to leverage the new features for better code and better > APIs. > > We need to start now and deprecate old compilers that do not support any C++11 > features at all. I I suggest requiring support for lambda as > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all > platforms that do not in Qt 5.6. > > daniel > > [1] ranged based for uses std::begin(container), which if not overloaded calls > container.begin(), which detaches. > > So using range-based can be used: > - If the container is const or > - If the container is unshared or > - To actually change the container's contents I do get what you mean, and I think they are all valid concerns. But I am wondering if the move to support/base Qt API more on top of modern C++ developments is not something that belongs in a major release instead of a minor one. I think there are quite a few APIs in Qt that may need reconsidering in this light. Would it not make more sense to introduce a break like that in a major release instead? Perhaps Qt 6 should not be in the too far future, and might be focused on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might be kept alive next to that for a while yet. Not just with bugfixes, but with whatever features are still feasible to backport to it. Question would be: if C++11 support could be dropped, what APIs would benefit from being re-designed? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto wrote: > > We need to start now and deprecate old compilers that do not support any > C++11 > > features at all. I I suggest requiring support for lambda as > > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating > all > > platforms that do not in Qt 5.6. > > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a > relatively new release), and BlackBerries. I personally would have loved to > remove support for 6.5.0, since it is based on an old gcc version that can > barely keep up with latest C++ developments (and keep giving me maintenance > headaches from time to time). But strategically (read, comercially) > speaking, > this is still not possible - QNX 6.5.0 is still widely deployed. > The move to 6.6.0 is happening at a slow pace - probably much slower > than the time it will take us to reach Qt 5.7. One of the many reasons for > that is that many of those systems running QNX are homologated and > changing/upgrading involves lots of different process apart from the > technical > stuff. > QNX 6.6 comes with GCC 4.7.3, which has lambda support: https://gcc.gnu.org/gcc-4.7/cxx0x_status.html Cheers, Cristian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 19 February 2015 at 14:17, Rafael Roquetto wrote: > One of the many reasons for that is that many of those systems running QNX > are homologated and > changing/upgrading involves lots of different process apart from the technical > stuff. So those companies/ users of QNX are not willing to upgrade their OS, compiler, but they are willing to upgrade Qt? In my experience, people who stick to old versions of operating systems are also not very keen on upgrading other software as well... so for them, it should not matter, whether the newest Qt version will drop old compiler support or not. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 02:25:27PM +0100, Cristian Adam wrote: > On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto > wrote: > > > > We need to start now and deprecate old compilers that do not support any > > C++11 > > > features at all. I I suggest requiring support for lambda as > > > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating > > all > > > platforms that do not in Qt 5.6. > > > > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a > > relatively new release), and BlackBerries. I personally would have loved to > > remove support for 6.5.0, since it is based on an old gcc version that can > > barely keep up with latest C++ developments (and keep giving me maintenance > > headaches from time to time). But strategically (read, comercially) > > speaking, > > this is still not possible - QNX 6.5.0 is still widely deployed. > > The move to 6.6.0 is happening at a slow pace - probably much slower > > than the time it will take us to reach Qt 5.7. One of the many reasons for > > that is that many of those systems running QNX are homologated and > > changing/upgrading involves lots of different process apart from the > > technical > > stuff. > > > > QNX 6.6 comes with GCC 4.7.3, which has lambda support: > https://gcc.gnu.org/gcc-4.7/cxx0x_status.html Indeed, but it builds against Dinkumware's libcpp, which has half-baked C++11 support (see https://codereview.qt-project.org/#/c/106599/ for one example). Cheers, Rafael > > Cheers, > Cristian. -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 02:27:32PM +0100, Tomasz Siekierda wrote: > On 19 February 2015 at 14:17, Rafael Roquetto > wrote: > > One of the many reasons for that is that many of those systems running QNX > > are homologated and > > changing/upgrading involves lots of different process apart from the > > technical > > stuff. > > So those companies/ users of QNX are not willing to upgrade their OS, > compiler, but they are willing to upgrade Qt? > > In my experience, people who stick to old versions of operating > systems are also not very keen on upgrading other software as well... > so for them, it should not matter, whether the newest Qt version will > drop old compiler support or not. And in my experience, it is not as simple as you put it... There are several cases where it does matter: for example: sometimes a company needs modules that are not available in previous Qt versions, such as qt3d or qtremoteobjects. Cheers, Rafael -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto wrote: > > > > QNX 6.6 comes with GCC 4.7.3, which has lambda support: > > https://gcc.gnu.org/gcc-4.7/cxx0x_status.html > > Indeed, but it builds against Dinkumware's libcpp, which has half-baked > C++11 > support (see https://codereview.qt-project.org/#/c/106599/ for one > example). > > Microsoft also uses Dinkumware's libcpp, but it seems Stephan T. Lavavej does a better job integrating it with the Visual C++ compiler. One can watch QNX's GCC activity here: http://community.qnx.com/integration/viewvc/viewvc.cgi/tools/?root=core-dev-tools&system=exsy1001 The most uptodate GCC is 4.9, no GCC 5.0 traces. Cheers, Cristian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
> On 19 Feb 2015, at 14:27, Tomasz Siekierda wrote: > > On 19 February 2015 at 14:17, Rafael Roquetto > wrote: >> One of the many reasons for that is that many of those systems running QNX >> are homologated and >> changing/upgrading involves lots of different process apart from the >> technical >> stuff. > > So those companies/ users of QNX are not willing to upgrade their OS, > compiler, but they are willing to upgrade Qt? > > In my experience, people who stick to old versions of operating > systems are also not very keen on upgrading other software as well... > so for them, it should not matter, whether the newest Qt version will > drop old compiler support or not. Often those customers aren’t new to QNX, but new to Qt. And often they need the latest and greatest Qt for some feature or bugfixes. Other third-party dependencies they can’t get migrated (or even recompiled) often make them stick to old QNX versions. Things tend to be somewhat more complicated than one might be used to, in the embedded world. -- Frank Osterfeld | frank.osterf...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
I agree that it would be nice to have this, but we can do quite a bit of things with the Qt abstraction of most new features. And for std::function you can add new interfaces for compilers that do support it without breaking old code, its done for move constructors and co already. Sure it would be nice to have all the nice new and nifty features, but then again even msvc 2010 only supports a subset of c++11 and msvc2013 still doesn't fully support c++11 or c++98, neither will old gccs. What is allowed what not. And then breaking in a minor version is not very customer friendly. Dropping this would for e.g. drop the support for WinCE. Of course we are also porting to WEC2013 and maybe Qt6 only supports WEC2013, whichs compiler supports most c++11 and a lot of the windows platform plugin code, but i agree with Andre that this is something for a major release. Right the support for old hardware/software stacks is a big plus for Qt. Thats because customers are sitting on those platforms and want to go into the future, but they can just do that when their old platform goes End of Life. So Qt offers them a way to already build the next generation software on their old stack and then switch over. This is a big selling point for Qt. Customers in aviation, medical, automotive and others have demands to support their products for 10-20 years. And they also have to certify their stack. So long point short, i would like to dicuss this for a move to Qt6 because of this and the points Andre mentioned already. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 19. Februar 2015, 14:26:34 schrieb André Somers: > Daniel Teske schreef op 19-2-2015 om 13:29: > > Hi, > > > > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 > > and C++14 added a lot of new good features. C++17 is planned to be a big > > step again. > > > > Qt needs to evolve together with C++ or it will be a outdated toolkit > > stuck in a C++98 world. > > > > As an example, Qt's container classes and C++11 range based for loop do > > not > > mix very well.[1] And for the same reason, the upcoming Ranges TS will not > > be too useful for Qt's container. > > > > We have started using some parts of C++11 in Creator a year ago and our > > experience is that lambdas (and std::function) are useful everywhere. > > Today we have more than 400 lambdas in Creator's source and have several > > interfaces that take a std::function. > > > > I would expect that allowing C++11 in Qt would similarly lead to a wider > > understanding on how to leverage the new features for better code and > > better APIs. > > > > We need to start now and deprecate old compilers that do not support any > > C++11 features at all. I I suggest requiring support for lambda as > > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating > > all > > platforms that do not in Qt 5.6. > > > > daniel > > > > [1] ranged based for uses std::begin(container), which if not overloaded > > calls container.begin(), which detaches. > > > > So using range-based can be used: > > - If the container is const or > > - If the container is unshared or > > - To actually change the container's contents > > I do get what you mean, and I think they are all valid concerns. But I > am wondering if the move to support/base Qt API more on top of modern > C++ developments is not something that belongs in a major release > instead of a minor one. I think there are quite a few APIs in Qt that > may need reconsidering in this light. Would it not make more sense to > introduce a break like that in a major release instead? > > Perhaps Qt 6 should not be in the too far future, and might be focused > on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might > be kept alive next to that for a while yet. Not just with bugfixes, but > with whatever features are still feasible to backport to it. > > Question would be: if C++11 support could be dropped, what APIs would > benefit from being re-designed? > > André > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote: > So long point short, i would like to dicuss this for a move to Qt6 because of > this and the points Andre mentioned already. +1 -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
> > Lähettäjä: development-bounces+tuukka.turunen=theqtcompany@qt-project.org > project.org> käyttäjän puolestaRafael Roquetto > Lähetetty: 19. helmikuuta 2015 17:03 > Vastaanottaja: Björn Breitmeyer > Kopio: development@qt-project.org > Aihe: Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't > support lambda > > On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote: > > > So long point short, i would like to dicuss this for a move to Qt6 because > > of > > this and the points Andre mentioned already. > +1 I think we should be able to address deprecation of old platform and compiler version also during the lifespan of Qt 5.x. I also do not think that time is yet right to make Qt 6, even though we are approaching the final Qt 4 releases :) In Qt 5.5 we are dropping quite many older platform and compiler versions in order to be able to support new, so doing same in Qt 5.6 is completely reasonable to consider. Stating this, I am not yet taking stand whether we need to go "all-in" with C++11 in Qt 5.6, but we should at least properly consider the pros and cons. We already see that Qt WebEngine benefits from newer compilers and there are also other things to be gained by being able to better leveraging capabilities provided by C++11. What comes to supporting older compilers and OS versions, that is of course a significant item to consider as well. The typical options there are to support only a subset of Qt functionality in these platforms as well as case by case leveraging back porting to bring features from new Qt versions on top of an older one. One extreme approach is also to make a special version of Qt for these platforms, if the need is big enough. And a rather commonly used approach is to have an extended support agreement to cover the needed product lifespan, therefore reducing the need of moving to a new version. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: > [1] ranged based for uses std::begin(container), which if not overloaded > calls container.begin(), which detaches. > > So using range-based can be used: > - If the container is const or > - If the container is unshared or > - To actually change the container's contents Sounds like the intended behaviour to me. What's wrong with this picture? -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote: > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: > > [1] ranged based for uses std::begin(container), which if not overloaded > > calls container.begin(), which detaches. > > > > So using range-based can be used: > > - If the container is const or > > - If the container is unshared or > > - To actually change the container's contents > > Sounds like the intended behaviour to me. What's wrong with this picture? You don't want to detach if you are only reading. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 17:32:11 Daniel Teske wrote: > On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote: > > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: > > > [1] ranged based for uses std::begin(container), which if not overloaded > > > calls container.begin(), which detaches. > > > > > > So using range-based can be used: > > > - If the container is const or > > > - If the container is unshared or > > > - To actually change the container's contents > > > > Sounds like the intended behaviour to me. What's wrong with this picture? > > You don't want to detach if you are only reading. Then make your container const. A cast or template function call that adds const is very easy. The design for the range-based for is that it can be used to mutate the container, so the above picture is exactly what is intended for that construct. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 19 February 2015 at 17:26, Thiago Macieira wrote: > Sounds like the intended behaviour to me. What's wrong with this picture? That on a non-const shared container for (auto i : container) will detach it. That's why having rules instead of saying "just use it", I guess... -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 07:29, Daniel Teske wrote:
> Qt's container classes and C++11 range based for loop do not mix very well.
> Ranged based for uses std::begin(container), which if not overloaded calls
> container.begin(), which detaches.
As an aside, the "correct" fix for this IMHO is for range-based for to
support a mechanism for marking the RHS 'const', whether or not it
otherwise would be so.
Worst case, Qt could (should?) implement something like:
struct QConstWrapper
{
ContainerType::const_iterator begin() const;
ContainerType::const_iterator end() const;
// remaining "magic" elided
};
QConstWrapper qConst(ContainerType const&);
That said, note that range-based for also differs from foreach in that
the former operates on the original container, whereas the latter
operates on a copy.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
> On 19 February 2015 at 17:26, Thiago Macieira
wrote:
> > Sounds like the intended behaviour to me. What's wrong with this picture?
>
> That on a non-const shared container
>
> for (auto i : container)
>
> will detach it. That's why having rules instead of saying "just use
> it", I guess...
And who says it's not what you wanted?
for (auto &i : container) {
if (i.startsWith("foo"))
i = bar;
}
--
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
> On 2015-02-19 07:29, Daniel Teske wrote:
> > Qt's container classes and C++11 range based for loop do not mix very
> > well.
> > Ranged based for uses std::begin(container), which if not overloaded calls
> > container.begin(), which detaches.
>
> As an aside, the "correct" fix for this IMHO is for range-based for to
> support a mechanism for marking the RHS 'const', whether or not it
> otherwise would be so.
>
> Worst case, Qt could (should?) implement something like:
>
> struct QConstWrapper
> {
> ContainerType::const_iterator begin() const;
> ContainerType::const_iterator end() const;
> // remaining "magic" elided
> };
>
> QConstWrapper qConst(ContainerType const&);
>
> That said, note that range-based for also differs from foreach in that
> the former operates on the original container, whereas the latter
> operates on a copy.
It actually needs to be:
template const T qConst(const T &t) { return t; }
It needs to create a copy and return it. There's a gotcha with range-based for
that it is defined in such a way that your temporaries may be destroyed before
the iteration. The standard defines it as:
{
auto && __range = ;
for ( auto __begin = std::begin(__range),
__end = std::end(__range);
__begin != __end;
++__begin ) {
= *__begin;
}
}
If you have a temporary in your right hand of the ':' it will get lifetime-
extended by that __range reference. Any other temporaries will get destroyed.
That means a cast works and a copy works. Returning a reference doesn't.
--
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 14:28, Thiago Macieira wrote:
> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>> That on a non-const shared container
>>
>> for (auto i : container)
>>
>> will detach it. That's why having rules instead of saying "just use
>> it", I guess...
>
> And who says it's not what you wanted?
>
> for (auto &i : container) {
> if (i.startsWith("foo"))
> i = bar;
> }
Correct me if I'm wrong, but:
auto c = expensive();
// assume 'c' is shared and a deep copy of c would be really expensive
foreach (auto const& item, c) { ... } // does not deep copy
for (auto const& item : c) { ... } // *does* deep copy; ouch!
I think the point here is that it's easy to incur deep copies using
range-based for when there is no need to do so. There really "needs" to
be a simple and concise way to stop that from happening.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 14:36, Thiago Macieira wrote:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not overloaded calls
>>> container.begin(), which detaches.
>>
>> As an aside, the "correct" fix for this IMHO is for range-based for to
>> support a mechanism for marking the RHS 'const', whether or not it
>> otherwise would be so.
>>
>> Worst case, Qt could (should?) implement something like:
>>
>> struct QConstWrapper
>> {
>> ContainerType::const_iterator begin() const;
>> ContainerType::const_iterator end() const;
>> // remaining "magic" elided
>> };
>>
>> QConstWrapper qConst(ContainerType const&);
>>
>> That said, note that range-based for also differs from foreach in that
>> the former operates on the original container, whereas the latter
>> operates on a copy.
>
> It actually needs to be:
>
> template const T qConst(const T &t) { return t; }
>
> It needs to create a copy and return it. There's a gotcha with range-based
> for
> that it is defined in such a way that your temporaries may be destroyed
> before
> the iteration. The standard defines it as:
>
> {
> auto && __range = ;
> for ( auto __begin = std::begin(__range),
> __end = std::end(__range);
> __begin != __end;
> ++__begin ) {
>= *__begin;
>
> }
> }
>
> If you have a temporary in your right hand of the ':' it will get lifetime-
> extended by that __range reference. Any other temporaries will get destroyed.
>
> That means a cast works and a copy works. Returning a reference doesn't.
You'll note that I did *not* return a reference.
Returning a copy may be okay for Qt since containers are COW (in fact,
your version would result in a range-based for that works much more like
Q_FOREACH, which is probably good for some cases). What I was aiming for
was rather a class that internally holds a reference to the container
(such class would be copyable) and forwards the calls to begin/end to
that container, such that in a range-based for it appears to *be* the
container, but forces use of const_iterator. Note that this would work
equally well for non-Qt containers, as long as they have 'IteratorType
{begin,end}() const' methods. (Trailing return specification may be
required to permit the container's iterator type to be unknown.)
I was initially thinking that this was perhaps simple enough to not be
worth it. Given your point, I am leaning more toward that it *would* be
valuable.
(I still think the best solution is for C++ to just accept 'const
' as a modifier to make the type of '' constant, regardless
of whether or not it was. This would allow things like 'for (auto item :
const container)', '(const this)->begin()', 'foo(const bar)', and so forth.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 13:29:48 Daniel Teske wrote: > more than 400 lambdas in Creator's source Sounds like lambdas are overused (as any new language feature is overused before it's fully understood by the resp. language community). > and have several interfaces > that take a std::function. What about boost::function? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 15:21, Marc Mutz wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>> more than 400 lambdas in Creator's source
>
> Sounds like lambdas are overused (as any new language feature is overused
> before it's fully understood by the resp. language community).
Maybe, maybe not.
I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
using them most often in QObject::connect. Basically, a lambda saves
writing a protected (or worse, *private*) slot by allowing the relevant
code to be written inline. These are rarely more than a few lines long,
and it's not unusual for them to be one-liners, e.g.:
connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
[d](int value){ d->scrollTo(value); });
The above is basically a private slot that's *actually private*. I've
also had cases of needing to connect a signal to a slot where the slot
needs to be called with additional (constant) arguments; these tend to
look like the above also.
Of course, the usual caveats of binding to a lambda apply, but in many
cases those aren't issues (e.g. my MainWindow class is not going to
disappear without taking its widgets with it, and said widgets aren't
likely to be emitting signals from other threads).
p.s. It would be cool if these restrictions could be relaxed by adding
an overload that takes a QObject that "owns" the slot.
>> and have several interfaces
>> that take a std::function.
>
> What about boost::function?
Ugh, make Qt depend on boost? No, thanks...
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
> > before it's fully understood by the resp. language community).
>
> Maybe, maybe not.
>
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
>
> connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
> [d](int value){ d->scrollTo(value); });
>
> The above is basically a private slot that's *actually private*. I've
> also had cases of needing to connect a signal to a slot where the slot
> needs to be called with additional (constant) arguments; these tend to
> look like the above also.
>
> Of course, the usual caveats of binding to a lambda apply, but in many
> cases those aren't issues (e.g. my MainWindow class is not going to
> disappear without taking its widgets with it, and said widgets aren't
> likely to be emitting signals from other threads).
>
> p.s. It would be cool if these restrictions could be relaxed by adding
> an overload that takes a QObject that "owns" the slot.
http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2)
Isn't that what you need?
- Resolves issues with thread-affinity (via QueuedConnection if req.)
- Automatic disconnect when the receiver/context is destroyed
>
> >> and have several interfaces
> >> that take a std::function.
> >
> > What about boost::function?
>
> Ugh, make Qt depend on boost? No, thanks...
Greets
--
Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thu, Feb 19, 2015 at 03:41:42PM -0500, Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
> > before it's fully understood by the resp. language community).
>
> Maybe, maybe not.
>
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
>
> connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
> [d](int value){ d->scrollTo(value); });
That's one (good) example.
Another one would be to avoid passing data through QAction::data
and using QObject::sender() in cases like
void someSlot()
{
const QAction *action = qobject_cast(sender());
/* FIXME: check action */
Data data = action->data().value();
foo()->useData(data);
}
/* ... possibly lots of lines inbetween ... */
{
...
Data data = /*...*/;
QAction *action = new QAction(...)
action->setData(data);
connect(action, &QAction::triggered, this, &ThisClass::someSlot);
...
}
vs:
{
...
Data data = /*...*/;
QAction *act = new QAction(...)
connect(act, &QAction::triggered, [this, data] { foo()->useData(data); }
...
}
This is less than half the code, is type-safe, an keeps related code in
one place. One line to express one idea. No awkward boilerplate.
Andre'
PS: I probably should praise Olivier more often for the new connect syntax.
Personally I think that's the #1 feature in Qt 5. It makes a real (positive)
difference in Qt application development.
PPS:
> > What about boost::function?
>
> Ugh, make Qt depend on boost? No, thanks...
*grin*
Indeed.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
NO, please. Just use std::cref(). The feature is there already in the STL.
Am 19.02.2015 um 20:36 schrieb Thiago Macieira:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not overloaded calls
>>> container.begin(), which detaches.
>>
>> As an aside, the "correct" fix for this IMHO is for range-based for to
>> support a mechanism for marking the RHS 'const', whether or not it
>> otherwise would be so.
>>
>> Worst case, Qt could (should?) implement something like:
>>
>>struct QConstWrapper
>>{
>> ContainerType::const_iterator begin() const;
>> ContainerType::const_iterator end() const;
>> // remaining "magic" elided
>>};
>>
>>QConstWrapper qConst(ContainerType const&);
>>
>> That said, note that range-based for also differs from foreach in that
>> the former operates on the original container, whereas the latter
>> operates on a copy.
>
> It actually needs to be:
>
> template const T qConst(const T &t) { return t; }
>
> It needs to create a copy and return it. There's a gotcha with range-based for
> that it is defined in such a way that your temporaries may be destroyed before
> the iteration. The standard defines it as:
>
> {
> auto && __range = ;
> for ( auto __begin = std::begin(__range),
> __end = std::end(__range);
> __begin != __end;
> ++__begin ) {
>= *__begin;
>
> }
> }
>
> If you have a temporary in your right hand of the ':' it will get lifetime-
> extended by that __range reference. Any other temporaries will get destroyed.
>
> That means a cast works and a copy works. Returning a reference doesn't.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Am 19.02.2015 um 20:47 schrieb Matthew Woehlke:
> On 2015-02-19 14:28, Thiago Macieira wrote:
>> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>>> That on a non-const shared container
>>>
>>> for (auto i : container)
>>>
>>> will detach it. That's why having rules instead of saying "just use
>>> it", I guess...
>>
>> And who says it's not what you wanted?
>>
>> for (auto &i : container) {
>> if (i.startsWith("foo"))
>> i = bar;
>> }
>
> Correct me if I'm wrong, but:
>
>auto c = expensive();
>
>// assume 'c' is shared and a deep copy of c would be really expensive
>
>foreach (auto const& item, c) { ... } // does not deep copy
>for (auto const& item : c) { ... } // *does* deep copy; ouch!
>
> I think the point here is that it's easy to incur deep copies using
> range-based for when there is no need to do so. There really "needs" to
> be a simple and concise way to stop that from happening.
Use std::cref() if not sure about your container's constness.
for (auto const& item : std::cref(c)) { ... }
But yes, I'd also prefer the C++ consortium would have opted for an
immutable range loop. "Optimize the common case, not the rare case".
Well, and for the code I usually write mutable range loops are a rare
exception. Also since we got the auto keyword mutable loops are
convenient to type now:
for (auto it = begin(c); it != end(c); ++i) { ... }
Not much longer than a range loop statement. But well, we won't change
that anymore, and at least I have no idea how to avoid that ugly
"std::cref()". Thinking now in the the direction of just teaching QML
about C++ standard containers and avoiding the Qt containers then. But
that also are crazy thoughts.
Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 16:27, Kevin Funk wrote: > On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote: >> p.s. It would be cool if these restrictions could be relaxed by adding >> an overload that takes a QObject that "owns" the slot. > > http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2) > > Isn't that what you need? > - Resolves issues with thread-affinity (via QueuedConnection if req.) > - Automatic disconnect when the receiver/context is destroyed Um... how'd I miss that? Thanks! :-) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
> Use std::cref() if not sure about your container's constness.
>
> for (auto const& item : std::cref(c)) { ... }
Do NOT do this. This will crash:
for (auto const &item : std::cref(somefunction()) { ... }
See my other email for an explanation.
And another reason is that std::cref is a C++11 Standard Library addition and
we cannot depend on that yet.
--
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 02/19/2015 09:41 PM, Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
>> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>>> more than 400 lambdas in Creator's source
>>
>> Sounds like lambdas are overused (as any new language feature is overused
>> before it's fully understood by the resp. language community).
>
> Maybe, maybe not.
>
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
>
>connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
>[d](int value){ d->scrollTo(value); });
>
> The above is basically a private slot that's *actually private*. I've
> also had cases of needing to connect a signal to a slot where the slot
> needs to be called with additional (constant) arguments; these tend to
> look like the above also.
This is also how I tend to use lambdas, and I agree they are great.
Especially for network requests, they are so much better than the old
style code.
But this is an implementation convenience only. You can't convince me to
drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win
CE or old gcc for blackberry or one of all the other answers that have
been given in those threads over the last couple of weeks.
Andrés question about how this would change the API is a lot more
interesting. I so far haven't seen a single case where someone has
described how access to lambdas might improve the API. If they are
there, I'd love to see them, because maybe this would teach me something
I haven't figured out yet.
Bo Thorsen,
Director, Viking Software.
--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
> -Original Message- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > [...] > But this is an implementation convenience only. You can't convince me to > drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win CE or > old gcc for blackberry or one of all the other answers that have been given in > those threads over the last couple of weeks. I tend to agree here, but Daniel raises a very valid point when he says: > I would expect that allowing C++11 in Qt would similarly lead to a wider > understanding on how to leverage the new features for better code and better > APIs. Since we don't use modern C++11 in Qt , its examples and documentation itself, there's little common understanding and best practices how to do so. So, short of using C++11 in Qt library code itself: How about if we encourage using C++11/C++14 features in examples and documentation snippets? To bootstrap this we might even do a 'porting week' once to crowd-source this... Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 February 2015 21:41:42 Matthew Woehlke wrote:
> connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
> [d](int value){ d->scrollTo(value); });
Indeed, I hadn't thought of private slots. Thanks for the reeducation.
Just make sure - and that's a big part of what I was trying to refer to - that
you don't use that statment in more than one function. Because identical
lambdas in different functions have different types, and thus templates they
are
passed to are instantiated anew each time. And compilers don't merge identical
executable code from different template instantiations (or do they)?
Cf. the commits that confine QStringLiteral to static inline functions to avoid
duplicating the QString array data for each use in a different function.
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 08:28:24 Koehne Kai wrote: > > -Original Message- > > From: development-bounces+kai.koehne=theqtcompany.com@qt- > > [...] > > But this is an implementation convenience only. You can't convince me to > > drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win > > CE or old gcc for blackberry or one of all the other answers that have > > been given in those threads over the last couple of weeks. > > I tend to agree here, but Daniel raises a very valid point when he says: > > I would expect that allowing C++11 in Qt would similarly lead to a wider > > understanding on how to leverage the new features for better code and > > better APIs. > Since we don't use modern C++11 in Qt , its examples and documentation > itself, there's little common understanding and best practices how to do > so. > > So, short of using C++11 in Qt library code itself: How about if we > encourage using C++11/C++14 features in examples and documentation > snippets? To bootstrap this we might even do a 'porting week' once to > crowd-source this... Sure. I already have added Q_DECL_OVERRIDE to all the examples in qtbase/examples. The examples are currently compiled as part of CI, but maybe we should start using lambda and auto in the examples and disabling the compilation of them on old compiler. Also, what about enabling C++11/14 by default on new projects? https://codereview.qt-project.org/106797 Or alternatively, making the CONFIG+=c++11 enabled by default or so. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 00:17:21 Mathias Hasselmann wrote: > NO, please. Just use std::cref(). The feature is there already in the STL. Sadly, attempts to do so are punished with error message not under 100 lines. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Bo Thorsen schreef op 20-2-2015 om 09:03: > Andrés question about how this would change the API is a lot more > interesting. I so far haven't seen a single case where someone has > described how access to lambdas might improve the API. If they are > there, I'd love to see them, because maybe this would teach me > something I haven't figured out yet. One example I could come up with as a potential new API is QSortFilterProxyModel. Currently, it requires subclassing to change the sort or the filter functions: it supplies protected filterAcceptsRow, filterAcceptsColumn and lessThan functions. I think that it would be much more convenient if these filters and the comparator could be supplied as a function object (a lambda, or a functor, or a std::mem_fn, anything callable as a function). While this wasn't all that practical in the past, I think C++/11 makes this much more convenient than subclassing. This could of course just be added, instead of replacing. But that would mean API bloat. Downside of replacing is of course: you break old code. I think that if we go over the Qt classes, we'll find more examples of where a subclass or a separate function that you need to write could be replaced with a more modern API. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 19 Feb 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> >
> > Sounds like lambdas are overused (as any new language feature is overused
> > before it's fully understood by the resp. language community).
That is a useless contribution to this discussion.
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
>
> connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
> [d](int value){ d->scrollTo(value); });
That's one area. The others are too replace trivial interfaces with a low
amount of virtual functions by a std::function properties. This can simplify
code if e.g. the different implementations don't fit into a nice hierarchy.
Also lambdas make the standard algorithm useful.
> The above is basically a private slot that's *actually private*. I've
> also had cases of needing to connect a signal to a slot where the slot
> needs to be called with additional (constant) arguments; these tend to
> look like the above also.
>
> Of course, the usual caveats of binding to a lambda apply, but in many
> cases those aren't issues (e.g. my MainWindow class is not going to
> disappear without taking its widgets with it, and said widgets aren't
> likely to be emitting signals from other threads).
>
> p.s. It would be cool if these restrictions could be relaxed by adding
> an overload that takes a QObject that "owns" the slot.
There is.
daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 11:26:31 Daniel Teske wrote: [...] > That's one area. The others are too replace trivial interfaces with a low > amount of virtual functions by a std::function properties. This can simplify > code if e.g. the different implementations don't fit into a nice hierarchy. Note that the Qt ABI (in practice, the Qt public API) cannot use std::function because we don't use stl types in our ABI. So we must roll our own (QFunction). (or change the policy) -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Olivier Goffart schreef op 20-2-2015 om 11:38: > On Friday 20 February 2015 11:26:31 Daniel Teske wrote: > [...] >> That's one area. The others are too replace trivial interfaces with a low >> amount of virtual functions by a std::function properties. This can simplify >> code if e.g. the different implementations don't fit into a nice hierarchy. > Note that the Qt ABI (in practice, the Qt public API) cannot use std::function > because we don't use stl types in our ABI. > > So we must roll our own (QFunction). > (or change the policy) > We already have, don't we? After all, QObject::connect takes a lambda or a function-like object... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 Feb 2015 00:17:00 Mathias Hasselmann wrote: > >>> [...] > >> [...] > > [...] > [...] I guess my point that the ranged based for loop and qt containers don't mix too well is now very much proven by the depth of this particular discussion. The upcoming Ranges TS has also uses std::begin and std::end. That means that qt containers will require special care to use with that TS. That is Qt is in danger of being hard to use with modern C++ in this area. My point is, if we don't use C++11 ourselves we won't find out in which areas Qt and modern C++ don't mix, and we won't fix them. We will be stuck being a C++98 toolkit that is slowly getting obsolete. daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
I fully agree with you, but, sadly, I think it will not be possible in 5.x. IMHO for the start we should use C++11/14 in the QPA plugins when we know for sure that the compiler supports these features.E.g. I already used (stashed) some C++11 features in the Android QPA, but sometime I got -1s because I used them ... Cheers,BogDan On Friday, February 20, 2015 12:53 PM, Daniel Teske wrote: On Friday 20 Feb 2015 00:17:00 Mathias Hasselmann wrote: > >>> [...] > >> [...] > > [...] > [...] I guess my point that the ranged based for loop and qt containers don't mix too well is now very much proven by the depth of this particular discussion. The upcoming Ranges TS has also uses std::begin and std::end. That means that qt containers will require special care to use with that TS. That is Qt is in danger of being hard to use with modern C++ in this area. My point is, if we don't use C++11 ourselves we won't find out in which areas Qt and modern C++ don't mix, and we won't fix them. We will be stuck being a C++98 toolkit that is slowly getting obsolete. daniel ___ 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 11:38:21 André Somers wrote: > Olivier Goffart schreef op 20-2-2015 om 11:38: > > On Friday 20 February 2015 11:26:31 Daniel Teske wrote: > > [...] > > > >> That's one area. The others are too replace trivial interfaces with a low > >> amount of virtual functions by a std::function properties. This can > >> simplify code if e.g. the different implementations don't fit into a > >> nice hierarchy.> > > Note that the Qt ABI (in practice, the Qt public API) cannot use > > std::function because we don't use stl types in our ABI. > > > > So we must roll our own (QFunction). > > (or change the policy) > > We already have, don't we? After all, QObject::connect takes a lambda or > a function-like object... YEs, but that's not std::function and that's not having the same feature QObject::connect takes a template type. Then QObject::connectImpl takes a QtPrivate::QSlotObjectBase which has it's own interface tight to the need of QObject::connect. If you wanted to support, implement, say, QSortFilterProxyModel::setFilter( cont std::function &filter) You would need a generic general purpose QFunction. For which you can specify the arguments as template parameter. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 11:15:32 BogDan wrote: > I fully agree with you, but, sadly, I think it will not be possible in 5.x. We started supporting C++98 during the course of Qt 4.x. We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and were able to finally use member template functions for example and deprecate qObjectFind and such. I don't see why we could not force C++11 during Qt 5.x lifetime. Remember that Qt 6 is in the very far future if it is going to ever exist. Qt 5 is there to stay a long time. At some point we are going to drop MSVC 2008 and GCC 4.4 The question is when. And to answer this question we can use the facts such as how many people are still needing it. Is supporting those worth the burden. > IMHO for the start we should use C++11/14 in the QPA plugins when we know > for sure that the compiler supports these features.E.g. I already used > (stashed) some C++11 features in the Android QPA, but sometime I got -1s > because I used them ... True, you should not get -1 for that. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Olivier Goffart schreef op 20-2-2015 om 12:32: > On Friday 20 February 2015 11:15:32 BogDan wrote: >> I fully agree with you, but, sadly, I think it will not be possible in 5.x. > We started supporting C++98 during the course of Qt 4.x. > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and > were able to finally use member template functions for example and deprecate > qObjectFind and such. > > I don't see why we could not force C++11 during Qt 5.x lifetime. > Remember that Qt 6 is in the very far future if it is going to ever exist. > Qt 5 is there to stay a long time. Why is that a given? You make it sound like this is fact of life, rather than a choice. And having Qt 6 would not automaticaly mean EOL for Qt 5 either, IMHO. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Den 20-02-2015 kl. 12:32 skrev Olivier Goffart: > On Friday 20 February 2015 11:15:32 BogDan wrote: >> I fully agree with you, but, sadly, I think it will not be possible in 5.x. > We started supporting C++98 during the course of Qt 4.x. > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and > were able to finally use member template functions for example and deprecate > qObjectFind and such. > > I don't see why we could not force C++11 during Qt 5.x lifetime. > Remember that Qt 6 is in the very far future if it is going to ever exist. > Qt 5 is there to stay a long time. > > At some point we are going to drop MSVC 2008 and GCC 4.4 > The question is when. > And to answer this question we can use the facts such as how many people are > still needing it. Is supporting those worth the burden. Since we're talking about lambdas, it's MSVC 2010 as well. I don't know what the status of lambdas is in MSVC 2012, since almost no one seems to use it. 2013 is the first fairly decent C++11 compiler. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
El Friday 20 February 2015, André Somers escribió: > Olivier Goffart schreef op 20-2-2015 om 11:38: > > On Friday 20 February 2015 11:26:31 Daniel Teske wrote: > > [...] > > > >> That's one area. The others are too replace trivial interfaces with a > >> low amount of virtual functions by a std::function properties. This can > >> simplify code if e.g. the different implementations don't fit into a > >> nice hierarchy. > > > > Note that the Qt ABI (in practice, the Qt public API) cannot use > > std::function because we don't use stl types in our ABI. > > > > So we must roll our own (QFunction). > > (or change the policy) > > We already have, don't we? After all, QObject::connect takes a lambda or > a function-like object... But that class is QtPrivate::FunctionPointer (aka PointerToMemberFunction in the docs) which obviously is not public. There was this discussion on qt- interest on wether one could use that type for ones own classes: http://lists.qt-project.org/pipermail/interest/2014-December/014465.html -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
El Thursday 19 February 2015, Tomasz Siekierda escribió: > So those companies/ users of QNX are not willing to upgrade their OS, > compiler, but they are willing to upgrade Qt? I think the main problem with requiring a very up to date Qt is that sometimes only newer versions of Qt have bugfixes. In a previous project we found the QSettings bug that lost all the file contents. Luckyly we were on 5.2, so we could backport the fix that I think landed only on 5.3 or 5.4, but people on 4.8 could not do it, since the fix required using QLockFile and QSaveFile, not in Qt4. The solution is of course having an LTS release that receives bugfixes, and that's already being worked as per Tuuka's previous emails. Is of course a lot of work, since once the LTS is released and newer versions diverge from it, things have to be done twice. And since not all contributions can be applied to both branches (e.g. the previous example), and people might still need the fixes, we would be back to square one. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Olivier Goffart schreef op 20-2-2015 om 12:22: > On Friday 20 February 2015 11:38:21 André Somers wrote: >> Olivier Goffart schreef op 20-2-2015 om 11:38: >>> On Friday 20 February 2015 11:26:31 Daniel Teske wrote: >>> [...] >>> That's one area. The others are too replace trivial interfaces with a low amount of virtual functions by a std::function properties. This can simplify code if e.g. the different implementations don't fit into a nice hierarchy.> >>> Note that the Qt ABI (in practice, the Qt public API) cannot use >>> std::function because we don't use stl types in our ABI. >>> >>> So we must roll our own (QFunction). >>> (or change the policy) >> We already have, don't we? After all, QObject::connect takes a lambda or >> a function-like object... > YEs, but that's not std::function and that's not having the same feature > > QObject::connect takes a template type. > Then QObject::connectImpl takes a QtPrivate::QSlotObjectBase which has it's > own interface tight to the need of QObject::connect. > > If you wanted to support, implement, say, > QSortFilterProxyModel::setFilter( > cont std::function &filter) > > You would need a generic general purpose QFunction. For which you can specify > the arguments as template parameter. > Ok, thanks for the clarification. And that's exactly the kind of thing I'd like to see supported. Though I'd rather not have the QFunction then, but just be able to use std::function. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 12:43:18 Bo Thorsen wrote: > Den 20-02-2015 kl. 12:32 skrev Olivier Goffart: > > At some point we are going to drop MSVC 2008 and GCC 4.4 [...] > Since we're talking about lambdas, it's MSVC 2010 as well. I don't know > what the status of lambdas is in MSVC 2012, since almost no one seems to > use it. > 2013 is the first fairly decent C++11 compiler. MSVC 2010 support lambdas. MSVC 2010 already has support for some C+11 feature, including lambda, auto, decltype, nullptr, rvalue ref, static_assert. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 20 February 2015 at 12:52, Alejandro Exojo wrote: > El Thursday 19 February 2015, Tomasz Siekierda escribió: >> So those companies/ users of QNX are not willing to upgrade their OS, >> compiler, but they are willing to upgrade Qt? > > I think the main problem with requiring a very up to date Qt is that sometimes > only newer versions of Qt have bugfixes. Same is true for the OSes and compilers... In any case, I don't mind much. It would be nice to see Qt deprecate old compilers, but if the general public says "no", then so be it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Sorry for interupting the discussion, but i saw mentioning of a range-based-for, so i have a question. std::map/unordered_map uses std::pair as a value type, and map::iterator::operator* returns reference to a pair, while Qt doesn't have an underlying struct and operator* returns ref to T (without a Key). So, using range-based-for (and foreach) with Qt containers doesn't allow to have an access to a key. Should this behavior be changed in the future (yes, this breaks source compatibility)? 2015-02-20 15:02 GMT+03:00 Tomasz Siekierda : > On 20 February 2015 at 12:52, Alejandro Exojo wrote: > > El Thursday 19 February 2015, Tomasz Siekierda escribió: > >> So those companies/ users of QNX are not willing to upgrade their OS, > >> compiler, but they are willing to upgrade Qt? > > > > I think the main problem with requiring a very up to date Qt is that > sometimes > > only newer versions of Qt have bugfixes. > > Same is true for the OSes and compilers... > > In any case, I don't mind much. It would be nice to see Qt deprecate > old compilers, but if the general public says "no", then so be it. > ___ > 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote: > On Friday 20 February 2015 11:15:32 BogDan wrote: > > I fully agree with you, but, sadly, I think it will not be possible in 5.x. > > We started supporting C++98 during the course of Qt 4.x. > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and > were able to finally use member template functions for example and deprecate > qObjectFind and such. This works when there are alternatives. In the case of QNX, *if* this has the side effect of Qt not being able to be built against 6.6.0 (perhaps they will have a newer compiler until then, but I can't assume that), then you need to deprecate the entire platform. -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
El Friday 20 February 2015, Tomasz Siekierda escribió: > On 20 February 2015 at 12:52, Alejandro Exojo wrote: > > El Thursday 19 February 2015, Tomasz Siekierda escribió: > >> So those companies/ users of QNX are not willing to upgrade their OS, > >> compiler, but they are willing to upgrade Qt? > > > > I think the main problem with requiring a very up to date Qt is that > > sometimes only newer versions of Qt have bugfixes. > > Same is true for the OSes and compilers... Only in some platforms, because the release pace of an OS tends to be much slower. The example of QNX is 6.5 version published on 2010, with 6.6 released on 2014. Qt releases are a lot faster. Now Microsoft and Apple are releasing faster as well, but remember how long XP was supported and it had a non negligible market share that app developers had to target. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote: > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote: > > On Friday 20 February 2015 11:15:32 BogDan wrote: > > > I fully agree with you, but, sadly, I think it will not be possible in > > > 5.x. > > > > We started supporting C++98 during the course of Qt 4.x. > > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and > > were able to finally use member template functions for example and > > deprecate qObjectFind and such. > > This works when there are alternatives. In the case of QNX, *if* this has > the side effect of Qt not being able to be built against 6.6.0 (perhaps > they will have a newer compiler until then, but I can't assume that), then > you need to deprecate the entire platform. Yes. The same way we deprecated Mac OSX 10.6 during Qt 5.x lifetime, or Windows 9x during Qt 4.x lifetime. My point is that there is no reason to say that this won't happen in Qt 5.x lifetime. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote: > On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote: > > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote: > > > On Friday 20 February 2015 11:15:32 BogDan wrote: > > > > I fully agree with you, but, sadly, I think it will not be possible in > > > > 5.x. > > > > > > We started supporting C++98 during the course of Qt 4.x. > > > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) and > > > were able to finally use member template functions for example and > > > deprecate qObjectFind and such. > > > > This works when there are alternatives. In the case of QNX, *if* this has > > the side effect of Qt not being able to be built against 6.6.0 (perhaps > > they will have a newer compiler until then, but I can't assume that), then > > you need to deprecate the entire platform. > > Yes. The same way we deprecated Mac OSX 10.6 during Qt 5.x lifetime, or > Windows 9x during Qt 4.x lifetime. > > My point is that there is no reason to say that this won't happen in Qt 5.x > lifetime. Which is not ok. I got your point. But while it is reasonable to push users from Windows 9x or OS X 10.6, in the case of QNX, you will be pushing users away from Qt. In the case of QNX 6.5.0, one could even argue that they could update to 6.6.0 - something that is still not trivial at all. But you drop 6.6.0, you basically remove Qt from a giant slice of automotive, industrial and aerospacial markets. Let's bear this in mind before deciding to pull the plug. Cheers, Rafael > > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org > -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Regarding the bloat, why not add the new functions and mark the old ones as deprecated. Of course it bloats the default. But it would also mean we know which functions will vanish encourage people not to use deprecated functions for old code and have a compile option that doesn't compile deprecated code(Maybe that exists already). -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Freitag, 20. Februar 2015, 10:04:31 schrieb André Somers: > Bo Thorsen schreef op 20-2-2015 om 09:03: > > Andrés question about how this would change the API is a lot more > > interesting. I so far haven't seen a single case where someone has > > described how access to lambdas might improve the API. If they are > > there, I'd love to see them, because maybe this would teach me > > something I haven't figured out yet. > > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. > > This could of course just be added, instead of replacing. But that would > mean API bloat. Downside of replacing is of course: you break old code. > > I think that if we go over the Qt classes, we'll find more examples of > where a subclass or a separate function that you need to write could be > replaced with a more modern API. > > André > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 11:52:32 Rafael Roquetto wrote: > On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote: > > On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote: > > > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote: > > > > On Friday 20 February 2015 11:15:32 BogDan wrote: > > > > > I fully agree with you, but, sadly, I think it will not be possible > > > > > in > > > > > 5.x. > > > > > > > > We started supporting C++98 during the course of Qt 4.x. > > > > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) > > > > and > > > > were able to finally use member template functions for example and > > > > deprecate qObjectFind and such. > > > > > > This works when there are alternatives. In the case of QNX, *if* this > > > has > > > the side effect of Qt not being able to be built against 6.6.0 (perhaps > > > they will have a newer compiler until then, but I can't assume that), > > > then > > > you need to deprecate the entire platform. > > > > Yes. The same way we deprecated Mac OSX 10.6 during Qt 5.x lifetime, or > > Windows 9x during Qt 4.x lifetime. > > > > My point is that there is no reason to say that this won't happen in Qt > > 5.x > > lifetime. > > Which is not ok. > > I got your point. But while it is reasonable to push users from > Windows 9x or OS X 10.6, in the case of QNX, you will be pushing users > away from Qt. In the case of QNX 6.5.0, one could even argue that they > could update to 6.6.0 - something that is still not trivial at all. But you > drop 6.6.0, you basically remove Qt from a giant slice of automotive, > industrial and aerospacial markets. Let's bear this in mind before deciding > to pull the plug. I did not say we need to drop support TODAY. Qt 5.x is there for many more years. Now, back to the topic, it is true that if we want to start using C++11 in Qt we would need to find a solution for QNX. Is there really no way to use a more recent gcc or clang to target QNX 6.6 or 6.5? -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 2:26 AM, Thiago Macieira
wrote:
> On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
> > Use std::cref() if not sure about your container's constness.
> >
> > for (auto const& item : std::cref(c)) { ... }
>
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
>
> See my other email for an explanation.
>
> And another reason is that std::cref is a C++11 Standard Library addition
> and
> we cannot depend on that yet.
>
Disclaimer: i don't know a thing about the C++ committee and how they
handle papers. What follows might be completely irrelevant if the paper was
rejected. Do you know if it is?
I've read about this range-based-for stuff before and there was this paper
[1] that apparently wants to introduce the next generation of it. It would
introduce the syntax (WITHOUT auto!):
for (elem : range)
Which would be exactly the same as:
for (auto&& elem : range)
Now i wonder, even if that paper is accepted, would it solve the issue for
the Qt containers when that syntax would be used on them?
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 03:01:01PM +0100, Olivier Goffart wrote: > On Friday 20 February 2015 11:52:32 Rafael Roquetto wrote: > > On Fri, Feb 20, 2015 at 02:37:09PM +0100, Olivier Goffart wrote: > > > On Friday 20 February 2015 11:17:51 Rafael Roquetto wrote: > > > > On Fri, Feb 20, 2015 at 12:32:45PM +0100, Olivier Goffart wrote: > > > > > On Friday 20 February 2015 11:15:32 BogDan wrote: > > > > > > I fully agree with you, but, sadly, I think it will not be possible > > > > > > in > > > > > > 5.x. > > > > > > > > > > We started supporting C++98 during the course of Qt 4.x. > > > > > We dropped MSVC 6, in Qt 4.5 (despite there was still people using it) > > > > > and > > > > > were able to finally use member template functions for example and > > > > > deprecate qObjectFind and such. > > > > > > > > This works when there are alternatives. In the case of QNX, *if* this > > > > has > > > > the side effect of Qt not being able to be built against 6.6.0 (perhaps > > > > they will have a newer compiler until then, but I can't assume that), > > > > then > > > > you need to deprecate the entire platform. > > > > > > Yes. The same way we deprecated Mac OSX 10.6 during Qt 5.x lifetime, or > > > Windows 9x during Qt 4.x lifetime. > > > > > > My point is that there is no reason to say that this won't happen in Qt > > > 5.x > > > lifetime. > > > > Which is not ok. > > > > I got your point. But while it is reasonable to push users from > > Windows 9x or OS X 10.6, in the case of QNX, you will be pushing users > > away from Qt. In the case of QNX 6.5.0, one could even argue that they > > could update to 6.6.0 - something that is still not trivial at all. But you > > drop 6.6.0, you basically remove Qt from a giant slice of automotive, > > industrial and aerospacial markets. Let's bear this in mind before deciding > > to pull the plug. > > I did not say we need to drop support TODAY. Qt 5.x is there for many more > years. > > Now, back to the topic, it is true that if we want to start using C++11 in Qt > we would need to find a solution for QNX. Is there really no way to use a > more > recent gcc or clang to target QNX 6.6 or 6.5? The only way afaik is if they release a service pack with an updated compiler. The QNX toolchain is shipped in the form of what they call an SDP (Software Development Kit), which ships everything from target libraries, host tools, and an IDE called Momentics. It is not really modular to the point we could independently switch compilers. Now, having said that, QNX 6.6.0 is gcc 4.7 based. Compiler-wise, that should be enough for lambdas, but correct me if I am wrong. The problem with 6.6.0 starts to arise when we decide to use features that their libcpp does not support. QNX 6.5.0 OTOH is gcc 4.4.2 based, and its libcpp does not support C++11. What kind of changes, apart from lambdas, are we willing to push in practice? I will investigate what can be done in practice to try to work around this from the QNX side. Thanks, Rafael > > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 3:56 PM, Rafael Roquetto wrote: > > Now, having said that, QNX 6.6.0 is gcc 4.7 based. Compiler-wise, that > should > be enough for lambdas, but correct me if I am wrong. > The problem with 6.6.0 starts to arise when we > decide to use features that their libcpp does not support. > > QNX 6.5.0 OTOH is gcc 4.4.2 based, and its libcpp does not support C++11. > > What kind of changes, apart from lambdas, are we willing to push in > practice? > I will investigate what can be done in practice to try to work around this > from the QNX side. > > There is another option for QNX, use libstdc++ from GCC and not libcpp from Dinkumware. But then again Rafael knows more about this: http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981 Is it not possible to have applications using only libstdc++? Cheers, Cristian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 15:24:04 Mark Gaiser wrote: > I've read about this range-based-for stuff before and there was this paper > [1] that apparently wants to introduce the next generation of it. It would > introduce the syntax (WITHOUT auto!): > for (elem : range) > > Which would be exactly the same as: > for (auto&& elem : range) > > Now i wonder, even if that paper is accepted, would it solve the issue for > the Qt containers when that syntax would be used on them? No, it's just syntactic sugar. No change in effects. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 16:44:28 Cristian Adam wrote: > There is another option for QNX, use libstdc++ from GCC and not libcpp from > Dinkumware. > > But then again Rafael knows more about this: > http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981 > > Is it not possible to have applications using only libstdc++? The problem with libstdc++ is -- I guess, without being told -- its licence. It's a GPLv3 + exception library, so it has implications for device manufacturers. That's why QNX won't default to it. In turn, applications and Qt switching to it means full ABI break. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 09:49:57 Olivier Goffart wrote: > I already have added Q_DECL_OVERRIDE to all the examples in qtbase/examples. > The examples are currently compiled as part of CI, but maybe we should > start using lambda and auto in the examples and disabling the compilation > of them on old compiler. > > Also, what about enabling C++11/14 by default on new projects? > https://codereview.qt-project.org/106797 > Or alternatively, making the CONFIG+=c++11 enabled by default or so. Agreed and I would also say that it's perfectly acceptable for new features and especially new modules to require those compiler features. People might need to upgrade their Qt in old OSes to get bugfixes, but it doesn't follow that they need new features for old OSes. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 09:51:59 Marc Mutz wrote: > Just make sure - and that's a big part of what I was trying to refer to - > that you don't use that statment in more than one function. Because > identical lambdas in different functions have different types, and thus > templates they are passed to are instantiated anew each time. And compilers > don't merge identical executable code from different template > instantiations (or do they)? I don't think they can, unless they're running in LTO mode. They need to assume that you compare function pointers and thus each function needs a different entry point, even if they have the same code. The best you can expect is a different entry point that has an unconditional branch to the common code. > Cf. the commits that confine QStringLiteral to static inline functions to > avoid duplicating the QString array data for each use in a different > function. The compiler needs to make the same assumption here. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Fri, Feb 20, 2015 at 08:00:17AM -0800, Thiago Macieira wrote: > On Friday 20 February 2015 16:44:28 Cristian Adam wrote: > > There is another option for QNX, use libstdc++ from GCC and not libcpp from > > Dinkumware. > > > > But then again Rafael knows more about this: > > http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981 > > > > Is it not possible to have applications using only libstdc++? > > The problem with libstdc++ is -- I guess, without being told -- its licence. > It's a GPLv3 + exception library, so it has implications for device > manufacturers. That's why QNX won't default to it. > > In turn, applications and Qt switching to it means full ABI break. In addition to that, things like harfbuzz and other libs shipped as part of the SDP are built against libcpp (dinkum), meaning that we need to stick with it if we want to link against those libs (as Qt does). > -- > 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 -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 12:52:31 André Somers wrote: > > If you wanted to support, implement, say, > > QSortFilterProxyModel::setFilter( > > cont std::function &filter) > > > > You would need a generic general purpose QFunction. For which you can > > specify the arguments as template parameter. > > Ok, thanks for the clarification. And that's exactly the kind of thing > I'd like to see supported. Though I'd rather not have the QFunction > then, but just be able to use std::function. A QFunction needs to accept an argument of std::function just as much as it needs to accept a real function of type T, so whether we take one or the other in our ABI would not diminish your capabilities in any way. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 04:04, André Somers wrote: > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. While that would certainly work... I'm not entirely convinced I would actually use it. Not with lambdas, anyway, unless they just handed off to member functions anyway. This sort of thing is above my threshold of 'things I'd want in inline (source-inline, i.e. lambdas) functions'. That said... QThread. Taking a functor that can be a lambda for something like QtConcurrent::run (which I think may already do this) or to replace the run() of a QThread seems useful. There are probably other examples along similar lines as QThread and QSortFilterProxyModel where currently one must override a virtual method that might be much easier to use a stateful functor instead. Another thing that might be useful is variadic templates. I suspect there are a number of places that right now have overloads for 0-N / 1-N arguments or use default parameters to achieve similar effects that could use variadic templates instead. (QMetaObject::invokeMethod and QString::arg come to mind...) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 07:10, Иван Комиссаров wrote: > Sorry for interupting the discussion, but i saw mentioning of a > range-based-for, so i have a question. std::map/unordered_map uses > std::pair as a value type, and map::iterator::operator* returns reference > to a pair, while Qt doesn't have an underlying struct and operator* returns > ref to T (without a Key). So, using range-based-for (and foreach) with Qt > containers doesn't allow to have an access to a key. > Should this behavior be changed in the future (yes, this breaks source > compatibility)? No. No need. (Also... note that foreach doesn't give you keys either.) You can instead wrap the container in an iterator wrapper that gives you iterators rather than values. (I have code somewhere, but not sure I have permission to share it.) No SIC, and you can still iterate directly over values. It's not entirely unlike the trick to do: for (auto const i : qtIndexRange(5)) ...and looks like: for (auto const i : qtEnumerate(map)) Maybe it would be nice for Qt to provide one or both of these? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-19 20:26, Thiago Macieira wrote:
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
Does it crash without the std::cref? If not... seems like a good
argument to support a free 'const'...
> And another reason is that std::cref is a C++11 Standard Library addition and
> we cannot depend on that yet.
...but so is range-based for (and auto).
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
> for (auto const i : qtEnumerate(map))
>
> Maybe it would be nice for Qt to provide one or both of these?
Sounds easy enough. Want to give it a try?
Note that this should also work for foreach:
foreach (const auto i, qtEnumerate(map))
Something like:
template
struct QEnumerateMap : private Map
{
struct const_iterator {
typename Map::iterator i;
iterator(typename Map::iterator i) : i(i) {}
// need to return by value
std::pair
value() const
{ return std::make_pair(i.key(), i.value()); }
};
const_iterator begin() const
{ return iterator(Map::begin()); }
const_iterator end() const
{ return iterator(Map::end()); }
};
--
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 13:37:16 Matthew Woehlke wrote:
> On 2015-02-19 20:26, Thiago Macieira wrote:
> > Do NOT do this. This will crash:
> > for (auto const &item : std::cref(somefunction()) { ... }
>
> Does it crash without the std::cref?
No, due to lifetime extension of the temporary.
> If not... seems like a good argument to support a free 'const'...
>
> > And another reason is that std::cref is a C++11 Standard Library addition
> > and we cannot depend on that yet.
>
> ...but so is range-based for (and auto).
That's different, those are core language features and we have Q_COMPILER_xxx
for them.
Standard Library features are more difficult to detect and even the library
providers are lagging behind:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
--
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 12:33:56 Matthew Woehlke wrote: > That said... QThread. Taking a functor that can be a lambda for > something like QtConcurrent::run (which I think may already do this) or > to replace the run() of a QThread seems useful. https://codereview.qt-project.org/89063 -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I'm happy to give you my headers; not sure when/if I'd have time to
clean them up as actual patches against Qt, however. For enumerate,
though, I technically need the customer's permission to share it.
> Note that this should also work for foreach:
>
> foreach (const auto i, qtEnumerate(map))
>
> Something like:
>
> template
> struct QEnumerateMap : private Map
> {
> struct const_iterator {
> typename Map::iterator i;
> iterator(typename Map::iterator i) : i(i) {}
>
> // need to return by value
> std::pair
> value() const
> { return std::make_pair(i.key(), i.value()); }
> };
>
> const_iterator begin() const
> { return iterator(Map::begin()); }
> const_iterator end() const
> { return iterator(Map::end()); }
> };
No, that doesn't seem right at all (unless you were going for a
non-broken cref?).
The way I did it is I construct a minimal class that has a reference to
the map (though, as discussed, this might need to be a copy), containing
a private iterator type, and begin()/end() methods. The private iterator
type is constructed from the container iterator, and needs to implement
its own operator++, operator== and operator*. The last one is key; it
returns the underlying iterator, rather than value() of the same.
Index range works on basically the same idea, only the 'underlying
iterator' is a number, you construct it from a number, and begin()
returns an iterator(0) while end returns an iterator(m_end). The
iterator needs the same operators, with the obvious implementations.
This all works with range-based for. Not sure about foreach...
One thing I notice you *did* get right is separating the utility class
from the function to create it; you do need to do this for template
deduction.
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 08:02:50 Thiago Macieira wrote: > On Friday 20 February 2015 09:49:57 Olivier Goffart wrote: > > I already have added Q_DECL_OVERRIDE to all the examples in > > qtbase/examples. The examples are currently compiled as part of CI, but > > maybe we should start using lambda and auto in the examples and disabling > > the compilation of them on old compiler. > > > > Also, what about enabling C++11/14 by default on new projects? > > https://codereview.qt-project.org/106797 > > Or alternatively, making the CONFIG+=c++11 enabled by default or so. > > Agreed and I would also say that it's perfectly acceptable for new features > and especially new modules to require those compiler features. Is that an actual rule or your opinion? There have been times that we would have liked to have been able to use C++11 in Qt3D. But, at the same time I'm very aware it would rule out WinCE from our list of possible targets at present. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 14:09:09 Rafael Roquetto wrote: > On Fri, Feb 20, 2015 at 08:00:17AM -0800, Thiago Macieira wrote: > > On Friday 20 February 2015 16:44:28 Cristian Adam wrote: > > > There is another option for QNX, use libstdc++ from GCC and not libcpp > > > from > > > Dinkumware. > > > > > > But then again Rafael knows more about this: > > > http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981 > > > > > > Is it not possible to have applications using only libstdc++? > > > > The problem with libstdc++ is -- I guess, without being told -- its > > licence. It's a GPLv3 + exception library, so it has implications for > > device manufacturers. That's why QNX won't default to it. > > > > In turn, applications and Qt switching to it means full ABI break. > > In addition to that, things like harfbuzz and other libs shipped as part of > the SDP are built against libcpp (dinkum), meaning that we need to stick > with it if we want to link against those libs (as Qt does). The best approach is likely to be for us to work with QNX to point out where their dinkumware libcpp has problems with specific examples, as we are doing regarding the recent constexpr support issue. I'm sure QNX will be happy to get pointers as to where they can make improvements to be more standard compliant. Regards, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Just want to throw in my "foreach key/value" loop implementation, as an
extension of "foreach", which I did years ago just as a proof of
concept.
http://codereview.stackexchange.com/questions/11681/
It allows you to do:
foreachkv(auto key, auto value, map) {
// do sth with key / value
}
Its implementation follows straight out of how Q_FOREACH is implemented,
just adding another for-loop. I only implemented the GCC version back
then, though.
On 20.02.2015 18:53, Matthew Woehlke wrote:
> On 2015-02-20 07:10, Иван Комиссаров wrote:
>> Sorry for interupting the discussion, but i saw mentioning of a
>> range-based-for, so i have a question. std::map/unordered_map uses
>> std::pair as a value type, and map::iterator::operator* returns
>> reference
>> to a pair, while Qt doesn't have an underlying struct and operator*
>> returns
>> ref to T (without a Key). So, using range-based-for (and foreach) with
>> Qt
>> containers doesn't allow to have an access to a key.
>> Should this behavior be changed in the future (yes, this breaks source
>> compatibility)?
>
> No. No need. (Also... note that foreach doesn't give you keys either.)
>
> You can instead wrap the container in an iterator wrapper that gives
> you
> iterators rather than values. (I have code somewhere, but not sure I
> have permission to share it.) No SIC, and you can still iterate
> directly
> over values.
>
> It's not entirely unlike the trick to do:
>
> for (auto const i : qtIndexRange(5))
>
> ...and looks like:
>
> for (auto const i : qtEnumerate(map))
>
> Maybe it would be nice for Qt to provide one or both of these?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 10:46:41 Sebastian Lehmann wrote: > Its implementation follows straight out of how Q_FOREACH is implemented, > just adding another for-loop. I only implemented the GCC version back > then, though. Hi Sebastian I "upgraded" Q_FOREACH for 5.4 to make it more readable and optimisable. You may want to take a look at the new version. Mostly because it broke yours, as I removed QForeachContainer::brk. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 09:11:57 Sean Harmer wrote: > The best approach is likely to be for us to work with QNX to point out > where their dinkumware libcpp has problems with specific examples, as we > are doing regarding the recent constexpr support issue. I'm sure QNX will > be happy to get pointers as to where they can make improvements to be more > standard compliant. Stop shipping Dinkumware and go for either libstdc++ (GPLv3+exception) or for libc++ (MIT). -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 09:06:13 Sean Harmer wrote: > On Friday 20 February 2015 08:02:50 Thiago Macieira wrote: > > On Friday 20 February 2015 09:49:57 Olivier Goffart wrote: > > > I already have added Q_DECL_OVERRIDE to all the examples in > > > qtbase/examples. The examples are currently compiled as part of CI, but > > > maybe we should start using lambda and auto in the examples and > > > disabling > > > the compilation of them on old compiler. > > > > > > Also, what about enabling C++11/14 by default on new projects? > > > https://codereview.qt-project.org/106797 > > > Or alternatively, making the CONFIG+=c++11 enabled by default or so. > > > > Agreed and I would also say that it's perfectly acceptable for new > > features > > and especially new modules to require those compiler features. > > Is that an actual rule or your opinion? There have been times that we would > have liked to have been able to use C++11 in Qt3D. But, at the same time I'm > very aware it would rule out WinCE from our list of possible targets at > present. It's been a rule that you can require C++11 core language for some new features. The only example of a C++11 Standard Library feature dependency is the use of std::chrono, which is guarded by SD-6 __has_include(). It's up to you: do you think you're going to unduly limit your audience by using said feature? If so, don't do it. As Marc says, "C++98 support costs more". -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Rafael Roquetto wrote: > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a > relatively new release), and BlackBerries. I personally would have loved > to remove support for 6.5.0, since it is based on an old gcc version that > can barely keep up with latest C++ developments (and keep giving me > maintenance headaches from time to time). But strategically (read, > comercially) speaking, this is still not possible - QNX 6.5.0 is still > widely deployed. The move to 6.6.0 is happening at a slow pace - probably > much slower than the time it will take us to reach Qt 5.7. One of the many > reasons for that is that many of those systems running QNX are homologated > and changing/upgrading involves lots of different process apart from the > technical stuff. Can't you target the older OS with a newer compiler? That approach is working just fine for RHEL (see the Red Hat Developer Toolset). Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Sunday 22 February 2015 05:47:41 Kevin Kofler wrote: > Rafael Roquetto wrote: > > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a > > relatively new release), and BlackBerries. I personally would have loved > > to remove support for 6.5.0, since it is based on an old gcc version that > > can barely keep up with latest C++ developments (and keep giving me > > maintenance headaches from time to time). But strategically (read, > > comercially) speaking, this is still not possible - QNX 6.5.0 is still > > widely deployed. The move to 6.6.0 is happening at a slow pace - probably > > much slower than the time it will take us to reach Qt 5.7. One of the many > > reasons for that is that many of those systems running QNX are homologated > > and changing/upgrading involves lots of different process apart from the > > technical stuff. > > Can't you target the older OS with a newer compiler? That approach is > working just fine for RHEL (see the Red Hat Developer Toolset). Technically yes for QNX, not so for WinEC7. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 20 February 2015 at 16:28, Koehne Kai wrote: >> -Original Message- >> From: development-bounces+kai.koehne=theqtcompany.com@qt- >> [...] >> But this is an implementation convenience only. You can't convince me to >> drop VS2010 to be able to use them internally inside Qt. Or 2008 for Win CE >> or >> old gcc for blackberry or one of all the other answers that have been given >> in >> those threads over the last couple of weeks. > > I tend to agree here, but Daniel raises a very valid point when he says: > >> I would expect that allowing C++11 in Qt would similarly lead to a wider >> understanding on how to leverage the new features for better code and better >> APIs. > > Since we don't use modern C++11 in Qt , its examples and documentation > itself, there's little common understanding and best practices how to do so. > > So, short of using C++11 in Qt library code itself: How about if we encourage > using C++11/C++14 features in examples and documentation snippets? To > bootstrap this we might even do a 'porting week' once to crowd-source this... +1 Any plans for another "Qt Fix and Polish Week"? The previous one seemed very well-received. [1] Regards, Sze-Howe [1] http://blog.qt.io/blog/2014/09/22/qt-fix-and-polish-week/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
I think Kai's approach is probably what would work best for now. As much as I'd like to, we can't yet use C++11 features unconditionally inside the core of Qt itself as we'd loose a few platforms that we still need to support. But we can (and should) certainly use C++11 in our examples and documentation. In addition, I think we should enable C++11 support by default on all compilers that support it well enough. Cheers, Lars On 20/02/15 09:28, "Koehne Kai" wrote: >> -Original Message- >> From: development-bounces+kai.koehne=theqtcompany.com@qt- >> [...] >> But this is an implementation convenience only. You can't convince me to >> drop VS2010 to be able to use them internally inside Qt. Or 2008 for >>Win CE or >> old gcc for blackberry or one of all the other answers that have been >>given in >> those threads over the last couple of weeks. > >I tend to agree here, but Daniel raises a very valid point when he says: > >> I would expect that allowing C++11 in Qt would similarly lead to a >>wider understanding on how to leverage the new features for better code >>and better APIs. > >Since we don't use modern C++11 in Qt , its examples and documentation >itself, there's little common understanding and best practices how to do >so. > >So, short of using C++11 in Qt library code itself: How about if we >encourage using C++11/C++14 features in examples and documentation >snippets? To bootstrap this we might even do a 'porting week' once to >crowd-source this... > >Regards > >Kai >___ >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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
> On Feb 20, 2015, at 10:04 AM, André Somers wrote: > > Bo Thorsen schreef op 20-2-2015 om 09:03: >> Andrés question about how this would change the API is a lot more >> interesting. I so far haven't seen a single case where someone has >> described how access to lambdas might improve the API. Well, the new connect style is also already improved API. >> If they are >> there, I'd love to see them, because maybe this would teach me >> something I haven't figured out yet. > > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. We start using these kind of patterns more and more in Qt Creator. Another example in Qt might be virtual QWebView * QWebView::createWindow(QWebPage::WebWindowType type) [protected] which could instead be a setWindowFactory function (same in QWebEngine). > This could of course just be added, instead of replacing. But that would > mean API bloat. Downside of replacing is of course: you break old code. > > I think that if we go over the Qt classes, we'll find more examples of > where a subclass or a separate function that you need to write could be > replaced with a more modern API. > > André > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 04:04, André Somers wrote: > Bo Thorsen schreef op 20-2-2015 om 09:03: >> Andrés question about how this would change the API is a lot more >> interesting. I so far haven't seen a single case where someone has >> described how access to lambdas might improve the API. If they are >> there, I'd love to see them, because maybe this would teach me >> something I haven't figured out yet. > > One example I could come up with as a potential new API is > QSortFilterProxyModel. Currently, it requires subclassing to change the > sort or the filter functions: it supplies protected filterAcceptsRow, > filterAcceptsColumn and lessThan functions. I think that it would be > much more convenient if these filters and the comparator could be > supplied as a function object (a lambda, or a functor, or a std::mem_fn, > anything callable as a function). While this wasn't all that practical > in the past, I think C++/11 makes this much more convenient than > subclassing. On that note... a potential use I just ran into yesterday that I might use is *duck punching* (essentially what you're describing, but in a more general form). I am in the process of porting a multi-column item list from a somewhat ad-hoc implementation to one based on reusable classes. The new version uses a complex two-layer item model setup; an underlying model to track the raw data, and a proxy model to provide an appropriate representation of that data. This *almost* allows me to drop the old subclassed QTreeView in favor of a stock QTreeView... but there's a problem: one of the columns is a "star" that allows the user mark "interesting" items. The user should be able to toggle this just by clicking on the star icon. The old stuff handled this by simply overriding a mouse event handler for the view. The new stuff doesn't (yet?) have a subclassed view, and I'd really like to keep it that way. (I'd also really like to avoid creating a custom delegate widget just for this, as I'd then have to move the display logic to that rather than the proxy model; that's an undesirable duplication of code.) If this was in Python, I'd just replace the mouse event handler in the QTreeView :-). I could imagine it being useful in other situations also to be able to override the event handlers (not necessarily event(), but specific ones e.g. paint(), mouseMoveEvent(), keyPressEvent(), etc.) with a QFunction. p.s. besides being less elegant, installing an event filter doesn't seem to *work*; it doesn't see mouse events! -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-02-20 14:42, Thiago Macieira wrote:
> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote:
>> for (auto const i : qtEnumerate(map))
>>
>> Maybe it would be nice for Qt to provide one or both of these?
>
> Sounds easy enough. Want to give it a try?
I *finally* got permission to share this. Sorry it took so long.
The attached code, excluding the copyright notices, is hereby placed
into the Public Domain. Permission is also granted to use the attached
code under either the BSD license, as stated in the files themselves, or
pursuant to Kitware's CLA with Qt.
It is my hope that this is useful to other people. (Also that the first
one finds its way into STL eventually :-), though that's a bit OT for here.)
These are both C++11 code. At minimum, they'll need brace-initialization
changed to parentheses-initialization in order to build in C++03 mode.
However, qtIndexRange also uses trailing return type specification, and
I'm not sure it's possible to avoid that without losing type deduction,
which sort-of defeats the purpose. There are also lots of elided type
specifiers, though those are easy enough to add.
Personally, I wouldn't consider it a terrible loss if these were only
available in C++11-or-later mode, since they're intended to be used with
range-based for.
> Note that this should also work for foreach:
>
> foreach (const auto i, qtEnumerate(map))
I'm not sure if it will or not; it was designed to work in range-based
for, i.e. it supplies begin() and end(). I'm not sure if that's enough
to automagically work in Q_FOREACH.
Thiago, do you want me to take another look at integrating these into Qt
proper, or do you have it in hand?
--
Matthew
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither name of Kitware, Inc. nor the names of any contributors may be used
to endorse or promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Based on code written by Matthew Woehlke and used by permission.
*/
#ifndef __qtEnumerate_h
#define __qtEnumerate_h
//-
template class qtEnumerator
{
public:
class iterator;
qtEnumerator(Container const& container) : c(container) {}
iterator begin() const { return {c.begin()}; }
iterator end() const { return {c.end()}; }
protected:
Container const& c;
};
//-
template class qtEnumerator::iterator
{
public:
using Iterator = typename Container::const_iterator;
Iterator operator*() const { return i; }
iterator& operator++() { ++i; return *this; }
bool operator==(iterator const& other) const
{ return i == other.i; }
bool operator!=(iterator const& other) const
{ return i != other.i; }
protected:
friend class qtEnumerator;
iterator(Iterator const& iter) : i{iter} {}
Iterator i;
};
//-
template
qtEnumerator qtEnumerate(Container const& container)
{
return {container};
}
#endif
/*
Copyright 2015 Kitware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither name of Kitware, Inc. nor the names of any contributors may be used
to
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-04-30 16:04, Matthew Woehlke wrote: > On 2015-02-20 14:42, Thiago Macieira wrote: >> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote: >>> for (auto const i : qtEnumerate(map)) >>> >>> Maybe it would be nice for Qt to provide one or both of these? >> >> Sounds easy enough. Want to give it a try? > > I *finally* got permission to share this. Sorry it took so long. > > The attached code, excluding the copyright notices, is hereby placed > into the Public Domain. Permission is also granted to use the attached > code under either the BSD license, as stated in the files themselves, or > pursuant to Kitware's CLA with Qt. > > It is my hope that this is useful to other people. (Also that the first > one finds its way into STL eventually :-), though that's a bit OT for here.) > > These are both C++11 code. At minimum, they'll need brace-initialization > changed to parentheses-initialization in order to build in C++03 mode. > However, qtIndexRange also uses trailing return type specification, and > I'm not sure it's possible to avoid that without losing type deduction, > which sort-of defeats the purpose. There are also lots of elided type > specifiers, though those are easy enough to add. > > Personally, I wouldn't consider it a terrible loss if these were only > available in C++11-or-later mode, since they're intended to be used with > range-based for. > >> Note that this should also work for foreach: >> >> foreach (const auto i, qtEnumerate(map)) > > I'm not sure if it will or not; it was designed to work in range-based > for, i.e. it supplies begin() and end(). I'm not sure if that's enough > to automagically work in Q_FOREACH. > > Thiago, do you want me to take another look at integrating these into Qt > proper, or do you have it in hand? Ping? -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Wednesday 13. May 2015 09:45:30 Matthew Woehlke wrote: > On 2015-04-30 16:04, Matthew Woehlke wrote: > > On 2015-02-20 14:42, Thiago Macieira wrote: > >> On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote: > >>> for (auto const i : qtEnumerate(map)) > >>> > >>> Maybe it would be nice for Qt to provide one or both of these? > >> > >> Sounds easy enough. Want to give it a try? > > > > I *finally* got permission to share this. Sorry it took so long. > > > > The attached code, excluding the copyright notices, is hereby placed > > into the Public Domain. Permission is also granted to use the attached > > code under either the BSD license, as stated in the files themselves, or > > pursuant to Kitware's CLA with Qt. > > > > It is my hope that this is useful to other people. (Also that the first > > one finds its way into STL eventually :-), though that's a bit OT for > > here.) > > > > These are both C++11 code. At minimum, they'll need brace-initialization > > changed to parentheses-initialization in order to build in C++03 mode. > > However, qtIndexRange also uses trailing return type specification, and > > I'm not sure it's possible to avoid that without losing type deduction, > > which sort-of defeats the purpose. There are also lots of elided type > > specifiers, though those are easy enough to add. > > > > Personally, I wouldn't consider it a terrible loss if these were only > > available in C++11-or-later mode, since they're intended to be used with > > range-based for. > > > >> Note that this should also work for foreach: > >>foreach (const auto i, qtEnumerate(map)) > > > > I'm not sure if it will or not; it was designed to work in range-based > > for, i.e. it supplies begin() and end(). I'm not sure if that's enough > > to automagically work in Q_FOREACH. > > > > Thiago, do you want me to take another look at integrating these into Qt > > proper, or do you have it in hand? > > Ping? If you want to integrate something to Qt you need to upload the contribution through gerrit. I'm afraid your solution is not working with temporaries containers. -- 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
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: > I'm afraid your solution is not working with temporaries containers. That should be submitted as a change request to the standard. There are a couple of other cases where this bites people. It needs a new paper. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-05-14 10:58, Thiago Macieira wrote: > On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: >> I'm afraid your solution is not working with temporaries containers. > > That should be submitted as a change request to the standard. There are a > couple of other cases where this bites people. > > It needs a new paper. Can you (both) please elaborate? That's... interesting. I'm taking a copy of the container and taking iterators from the copy. It seems to me that the RHS expression in a range-based for should most definitely not go out of scope within the for. Is that not the case? (Does range-based for just not work on temporaries at all?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote: > On 2015-05-14 10:58, Thiago Macieira wrote: > > On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: > >> I'm afraid your solution is not working with temporaries containers. > > > > That should be submitted as a change request to the standard. There are a > > couple of other cases where this bites people. > > > > It needs a new paper. > > Can you (both) please elaborate? > > That's... interesting. I'm taking a copy of the container and taking > iterators from the copy. It seems to me that the RHS expression in a > range-based for should most definitely not go out of scope within the > for. Is that not the case? (Does range-based for just not work on > temporaries at all?) for (auto x : function(function2())) If function returns a temporary and function passes through a reference, then it effectively returns a dangling reference. That's because there's a sequencing point shortly before the loop that causes all temporaries to be destroyed. See 6.5.4 [range.stmt] paragraph 1. It has an expansion of what the range for is supposed to do. Note the presence of a semi-colon before the "for". -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On 2015-05-14 16:37, Thiago Macieira wrote: > On Thursday 14 May 2015 11:34:25 Matthew Woehlke wrote: >> On 2015-05-14 10:58, Thiago Macieira wrote: >>> On Thursday 14 May 2015 14:36:43 Olivier Goffart wrote: I'm afraid your solution is not working with temporaries containers. >>> >>> That should be submitted as a change request to the standard. There are a >>> couple of other cases where this bites people. >>> >>> It needs a new paper. >> >> Can you (both) please elaborate? >> >> That's... interesting. I'm taking a copy of the container and taking >> iterators from the copy. It seems to me that the RHS expression in a >> range-based for should most definitely not go out of scope within the >> for. Is that not the case? (Does range-based for just not work on >> temporaries at all?) > > for (auto x : function(function2())) > > If function returns a temporary and function passes through a reference, [...] Er... wait. My bad. Does it resolve the issue if 'Container const& c;' in qtEnumerator is changed to be a copy (i.e. remove the '&') rather than a reference? (I was thinking it was a copy when I wrote the above, and, given that this is likely only going to be used on Qt containers, it probably ought to be a copy.) Back on the subject of C++ standard proposals, I thought there was already a proposal regarding lifetime extension of temporaries? (Or did that die? Or not cover this use case?) -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 15 May 2015 10:42:54 Matthew Woehlke wrote: > > for (auto x : function(function2())) > > > > > > > > If function returns a temporary and function passes through a reference, > > [...] > Er... wait. My bad. Does it resolve the issue if 'Container const& c;' > in qtEnumerator is changed to be a copy (i.e. remove the '&') rather > than a reference? (I was thinking it was a copy when I wrote the above, > and, given that this is likely only going to be used on Qt containers, > it probably ought to be a copy.) If you copy the container into the wrapper, yes, it should work. -- 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 02:26:25 Thiago Macieira wrote:
> Do NOT do this. This will crash:
>
> for (auto const &item : std::cref(somefunction()) { ... }
Sorry for warming up an old thread, but since there was talk about the QtC
coding style recommending this...
It's safe for lvalues. What't not safe are rvalues, but the std:.cref()
overload from rvalues (const) is supposed to be deleted, according o en-
cppreference.com, so it shouldn't even compile. Doesn't help much if the
compiler doesn't know = delete, though.
This might work, based on the cref() overload pattern:
template
class QContainerWrapper {
T container;
friend decltype(auto) begin(const QContainerWrapper &w)
Q_DECL_NOEXCEPT_EXPR(noexcept(w.container.begin()))
{ return w.container.begin(); }
friend decltype(auto) end(const QContainerWrapper &w)
Q_DECL_NOEXCEPT_EXPR(noexcept(w.container.end()))
{ return w.container.end(); }
};
// assume the following are friends of QContainerWrapper, resp.:
template
QContainerWrapper qAsConst(const T &t) // lvalue
Q_DECL_NOTHROW
{ return {t}; } // stores reference
template
QContainerWrapper qAsConst(const T &&t)
Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v)
{ return {std::move(t)}; } // stores a copy
Untested!
Thanks,
Marc
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Wednesday 16 December 2015 15:01:23 Marc Mutz wrote:
> // assume the following are friends of QContainerWrapper,
> resp.: template
> QContainerWrapper qAsConst(const T &t) // lvalue
> Q_DECL_NOTHROW
> { return {t}; } // stores reference
> template
> QContainerWrapper qAsConst(const T &&t)
> Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v)
> { return {std::move(t)}; } // stores a copy
Actually, this would be even simpler:
template
Q_DECL_CONSTEXPR const T &qAsConst(const T &t) Q_DECL_NOTHROW
{ return t; }
template
Q_DECL_CONSTEXPR const T qAsConst(T &&t)
Q_DECL_NOEXCEPT_EXPR(std::is_nothrow_move_constructible_v)
{ return std::move(t); }
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
