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
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 daniel.te...@theqtcompany.com 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
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
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
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
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::functionbool(int, const QModelIndex) 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] qtLibraryTarget output changed from Qt 5.3.2 to Qt 5.4.0
On Fri, Feb 20, 2015 at 01:07:07PM +0200, William Hallatt wrote: On 20 February 2015 at 11:58, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: i presume the right approach would be admitting defeat, making a new internal function for qt, and restoring qtLibraryTarget() to its qt4 behavior. Would you like me to log a bug? well, why 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 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
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
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::functionbool(int, const QModelIndex) 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] qtLibraryTarget output changed from Qt 5.3.2 to Qt 5.4.0
On 20 February 2015 at 11:58, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: technically speaking, the function isn't documented at all and should be considered internal. I would never have known of its existence if it wasn't for the fact that the code I referenced from my project file was auto-generated by the QtCreator project template. however, all our plugin-related examples are littered with references to it, so it would be a bit hard to sweep it under the rug. i presume the right approach would be admitting defeat, making a new internal function for qt, and restoring qtLibraryTarget() to its qt4 behavior. Would you like me to log a bug? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Code Coverage Statistics for QtBase
I saw something interesting: If you have a look at the code coverage of gui/text, gui/kernel and gui/opengl you can see that the code coverage in Qt5.4 is about 50% and in Qt5/dev 0%! This is really strange: the tests executed are mostly the same and some of them are GUI tests. Why this big difference? I'm guessing if Qt5 is now not skipping some GUI driver if they are not used. For example, OpenGL is not used, then no code from gui/opengl is executed. If this is the case, it would be interesting to know if we can, for example, force Qt to use OpenGL (It makes sense for a test to execute it in OpenGL and non OpenGL mode). To view the code coverage: Qt5.4: http://download.froglogic.com/public/qt5-squishcoco-report/ref_QtBase_html/directories.html At5/dev: http://download.froglogic.com/public/qt5-squishcoco-report/QtBase_html/directories.html ___ 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 marc.m...@kdab.com | 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
[Development] qtLibraryTarget output changed from Qt 5.3.2 to Qt 5.4.0
Good day everyone, I upgraded from Qt 5.3.2 to Qt 5.4.0 yesterday and suddenly found that my QML plugin imports no longer worked. It turned out that the reason for this is the qtLibraryTarget output generation seems to have changed from Qt5.3.x to Qt 5.4.0 in that it now automatically adds a 5 to any TARGET value that starts with Qt In other words, in my plugin .pro, I have the following code: TEMPLATE = lib TARGET = QtQmlComponents QT += qml quick CONFIG += qt plugin TARGET = $$qtLibraryTarget($$TARGET) Which, for 5.3.x gave me QtQmlComponents.dll (on Windows obviously), but for 5.4 now gives me Qt5QmlComponents.dll. This broke absolutely everything. I understand that this is an edge case, but I was wondering if it is documented anywhere that one should NOT use Qt tags when writing plugins (or for anything else for that matter)? The way I see it, this is either a bug, or it should be explicitly stated in the documentation (provided that it isn't somewhere I haven't found) that one shouldn't do it as this took me hours to resolve. Opinions? Regards, William. ___ 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] qtLibraryTarget output changed from Qt 5.3.2 to Qt 5.4.0
On Fri, Feb 20, 2015 at 10:49:21AM +0200, William Hallatt wrote: TARGET = QtQmlComponents TARGET = $$qtLibraryTarget($$TARGET) Which, for 5.3.x gave me QtQmlComponents.dll (on Windows obviously), but for 5.4 now gives me Qt5QmlComponents.dll. I understand that this is an edge case, but I was wondering if it is documented anywhere that one should NOT use Qt tags when writing plugins (or for anything else for that matter)? The way I see it, this is either a bug, or it should be explicitly stated in the documentation (provided that it isn't somewhere I haven't found) that one shouldn't do it as this took me hours to resolve. technically speaking, the function isn't documented at all and should be considered internal. however, all our plugin-related examples are littered with references to it, so it would be a bit hard to sweep it under the rug. i presume the right approach would be admitting defeat, making a new internal function for qt, and restoring qtLibraryTarget() to its qt4 behavior. ___ 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 marc.m...@kdab.com | 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 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 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
On 20 February 2015 at 12:52, Alejandro Exojo s...@badopi.org 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 sierd...@gmail.com: On 20 February 2015 at 12:52, Alejandro Exojo s...@badopi.org 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
El Friday 20 February 2015, Tomasz Siekierda escribió: On 20 February 2015 at 12:52, Alejandro Exojo s...@badopi.org 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 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 thiago.macie...@intel.com
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 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) GmbHCo 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 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 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 typename Map
struct QEnumerateMap : private Map
{
struct const_iterator {
typename Map::iterator i;
iterator(typename Map::iterator i) : i(i) {}
// need to return by value
std::pairtypename Map::key_type, typename Map::value_type
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 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 Fri, Feb 20, 2015 at 3:56 PM, Rafael Roquetto rafael.roque...@kdab.com 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 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::functionbool(int, const QModelIndex) 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 QFunctionT needs to accept an argument of std::functionT 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
[Development] Not coming to Qt World Summit
As priorities go, Embedded Linux Conference Europe[1] and LinuxCon Europe[2] take precedence over the Qt World Summit. So short of someone coming up with practical cloning by then, I won't be able to come to Berlin. [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe [2] http://events.linuxfoundation.org/events/linuxcon-europe -- 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 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] REMINDER: Qt5.5 branching completion
just a reminder that on monday we do the final downmerge from dev to 5.5. what misses this merge won't be in 5.5 - no cherry-picks, as usual! now is a really good time to send me retargeting requests before hitting the stage button again. i'll also note that as with 5.3 before, 5.4 is NOT closed - continue to submit applicable important bugfixes there (in particular when they affect the build - the no-cherry-pick rule applies to older branches as well!). we'll let it slowly die after we actually release 5.5. On Mon, Feb 16, 2015 at 01:04:40PM +, Heikkinen Jani wrote: Hi all, Qt5.5 feature freeze branching period is now ongoing. '5.5' branch is created you should start using it for the changes targeted to Qt5.5 release. Again we will use 'soft branching' scheme like we did with 5.4.0. Downmerge from 'dev' to '5.5' will happen next Monday (23rd Feb) so there should be enough time to finalize ongoing changes in 'dev' start using '5.5'. After downmerge next Monday 'dev' branch will be for '5.6' release. As usual Ossi is taking re-targeting requests from 'dev' to '5.5' as well. br, Jani ___ 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 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 typename Map
struct QEnumerateMap : private Map
{
struct const_iterator {
typename Map::iterator i;
iterator(typename Map::iterator i) : i(i) {}
// need to return by value
std::pairtypename Map::key_type, typename Map::value_type
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
