Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Marc Mutz]

On Friday 20 February 2015 02:26:25 Thiago Macieira wrote:
> Do NOT do this. This will crash:
> 
> for (auto const  : 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 )
  Q_DECL_NOEXCEPT_EXPR(noexcept(w.container.begin()))
  { return w.container.begin(); }
  friend decltype(auto) end(const QContainerWrapper )
  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 ) // lvalue
  Q_DECL_NOTHROW
  { return {t}; } // stores reference
  template 
  QContainerWrapper qAsConst(const 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

[Marc Mutz]

On Wednesday 16 December 2015 15:01:23 Marc Mutz wrote:
>   // assume the following are friends of QContainerWrapper,
> resp.: template 
>   QContainerWrapper qAsConst(const T ) // lvalue
>   Q_DECL_NOTHROW
>   { return {t}; } // stores reference
>   template 
>   QContainerWrapper qAsConst(const 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 (const T ) Q_DECL_NOTHROW
{ return t; }
 template 
 Q_DECL_CONSTEXPR const T qAsConst(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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

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

[Thiago Macieira]

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

[Olivier Goffart]

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

[Matthew Woehlke]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Matthew Woehlke]

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

[Matthew Woehlke]

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 typename Container 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 typename Container class qtEnumeratorContainer::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 qtEnumeratorContainer;
iterator(Iterator const iter) : i{iter} {}

Iterator i;
};

//-
template typename Container
qtEnumeratorContainer 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 

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

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

[Ziller Eike]

 On Feb 20, 2015, at 10:04 AM, André Somers an...@familiesomers.nl 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

[Sze Howe Koh]

On 20 February 2015 at 16:28, Koehne Kai kai.koe...@theqtcompany.com 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

[Knoll Lars]

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 kai.koe...@theqtcompany.com 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

[Thiago Macieira]

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

[Kevin Kofler]

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

[Sean Harmer]

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

[Sebastian Lehmann]

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

[Sean Harmer]

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

[Thiago Macieira]

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(chrono).

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Olivier Goffart]

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

[BogDan]

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

[Bo Thorsen]

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

[Daniel Teske]

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

[André Somers]

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

[Daniel Teske]

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

[Olivier Goffart]

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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

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


 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

[André Somers]

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

[Alejandro Exojo]

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

[André Somers]

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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Marc Mutz]

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

[Olivier Goffart]

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

[Bo Thorsen]

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

[Koehne Kai]

 -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

[Marc Mutz]

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

[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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Olivier Goffart]

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

[Rafael Roquetto]

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

[Tomasz Siekierda]

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

[Alejandro Exojo]

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

[Olivier Goffart]

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

[Olivier Goffart]

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

[Mark Gaiser]

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

[Rafael Roquetto]

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

[Björn Breitmeyer]

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

[Rafael Roquetto]

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

[Matthew Woehlke]

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

[Thiago Macieira]

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

[Cristian Adam]

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

[Thiago Macieira]

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

[Rafael Roquetto]

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

[Thiago Macieira]

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

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

[Thiago Macieira]

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

[Matthew Woehlke]

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

[Matthew Woehlke]

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

[Matthew Woehlke]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Marc Mutz]

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

[Thiago Macieira]

On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
 On 19 February 2015 at 17:26, Thiago Macieira thiago.macie...@intel.com 
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

[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 QConstWrapperContainerType
   {
 ContainerType::const_iterator begin() const;
 ContainerType::const_iterator end() const;
 // remaining magic elided
   };
 
   QConstWrapperContainerType 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 typename T 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 = your range;
for ( auto __begin = std::begin(__range),
__end = std::end(__range);
__begin != __end;
++__begin ) {
for-range-declaration = *__begin;
statement
}
}

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

[Matthew Woehlke]

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 QConstWrapperContainerType
   {
 ContainerType::const_iterator begin() const;
 ContainerType::const_iterator end() const;
 // remaining magic elided
   };

   QConstWrapperContainerType 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 typename T 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 = your range;
   for ( auto __begin = std::begin(__range),
   __end = std::end(__range);
   __begin != __end;
   ++__begin ) {
   for-range-declaration = *__begin;
   statement
   }
 }
 
 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
expr' as a modifier to make the type of 'expr' 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

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

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

[Matthew Woehlke]

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

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto rafael.roque...@kdab.com
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

[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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Rafael Roquetto]

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

[Rafael Roquetto]

On Thu, Feb 19, 2015 at 02:25:27PM +0100, Cristian Adam wrote:
 On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto rafael.roque...@kdab.com
 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

[Rafael Roquetto]

On Thu, Feb 19, 2015 at 02:27:32PM +0100, Tomasz Siekierda wrote:
 On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com 
 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

[Tomasz Siekierda]

On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com 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

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto rafael.roque...@kdab.com
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-toolssystem=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

[Frank Osterfeld]

 On 19 Feb 2015, at 14:27, Tomasz Siekierda sierd...@gmail.com wrote:
 
 On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com 
 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) GmbHCo 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

[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

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
___
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]

On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
snip
 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

[Kevin Funk]

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

[André Pönitz]

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_castconst QAction *(sender());
/* FIXME: check action */
Data data = action-data().valueData();
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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Turunen Tuukka]

 Lähettäjä: development-bounces+tuukka.turunen=theqtcompany@qt-project.org 
 development-bounces+tuukka.turunen=theqtcompany.com@qt-
 project.org käyttäjän  puolestaRafael Roquetto rafael.roque...@kdab.com
 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:
 snip
  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

[Daniel Teske]

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

[Matthew Woehlke]

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 QConstWrapperContainerType
  {
ContainerType::const_iterator begin() const;
ContainerType::const_iterator end() const;
// remaining magic elided
  };

  QConstWrapperContainerType 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

[Björn Breitmeyer]

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) GmbHCo 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

[Giuseppe D'Angelo]

On 19 February 2015 at 17:26, Thiago Macieira thiago.macie...@intel.com 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

[Mathias Hasselmann]

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 QConstWrapperContainerType
{
  ContainerType::const_iterator begin() const;
  ContainerType::const_iterator end() const;
  // remaining magic elided
};

QConstWrapperContainerType 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 typename T 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 = your range;
   for ( auto __begin = std::begin(__range),
   __end = std::end(__range);
   __begin != __end;
   ++__begin ) {
   for-range-declaration = *__begin;
   statement
   }
 }

 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

[Mathias Hasselmann]

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

[Thiago Macieira]

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

[Matthew Woehlke]

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