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
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
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
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
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
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
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
On Fri, Feb 20, 2015 at 01:07:07PM +0200, William Hallatt wrote:
On 20 February 2015 at 11:58, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com wrote:
i presume the right approach would be admitting defeat, making a new
internal function for qt, and restoring qtLibraryTarget() to its
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
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
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
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
On 20 February 2015 at 11:58, Oswald Buddenhagen
oswald.buddenha...@theqtcompany.com wrote:
technically speaking, the function isn't documented at all and should be
considered internal.
I would never have known of its existence if it wasn't for the fact that
the code I referenced from my
I saw something interesting:
If you have a look at the code coverage of gui/text, gui/kernel and
gui/opengl you can see that the code coverage in Qt5.4 is about 50% and
in Qt5/dev 0%!
This is really strange: the tests executed are mostly the same and some
of them are GUI tests.
Why this big
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
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
Good day everyone,
I upgraded from Qt 5.3.2 to Qt 5.4.0 yesterday and suddenly found that my
QML plugin imports no longer worked. It turned out that the reason for
this is the qtLibraryTarget output generation seems to have changed from
Qt5.3.x to Qt 5.4.0 in that it now automatically adds a 5
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
-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
On Fri, Feb 20, 2015 at 10:49:21AM +0200, William Hallatt wrote:
TARGET = QtQmlComponents
TARGET = $$qtLibraryTarget($$TARGET)
Which, for 5.3.x gave me QtQmlComponents.dll (on Windows obviously), but
for 5.4 now gives me Qt5QmlComponents.dll.
I understand that this is an edge case, but I
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)
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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:
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
As priorities go, Embedded Linux Conference Europe[1] and LinuxCon Europe[2]
take precedence over the Qt World Summit. So short of someone coming up with
practical cloning by then, I won't be able to come to Berlin.
[1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe
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
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
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
just a reminder that on monday we do the final downmerge from dev to
5.5. what misses this merge won't be in 5.5 - no cherry-picks, as usual!
now is a really good time to send me retargeting requests before hitting
the stage button again.
i'll also note that as with 5.3 before, 5.4 is NOT closed
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
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
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,
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
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
49 matches
Mail list logo
