The most concise, I guess, is:
static const auto laterDeleter = std::mem_fn(&QObject::deleteLater);
std::unique_ptr a(nullptr, laterDeleter);
In C++17, if I don't mistake, you won't ned explicit type specifier in the
template, so it shortens to:
std::unique_ptr a(nullptr, std::mem_fn(&QObject::de
Using Qt 5.7.1 on OSX and building for Android,
import QtQuick 2.7
import QtQuick.Controls 1.5
For TextInput, I receive Key.OnPressed for standard keys like A->Z,1-9, etc.
But for TextEdit, No events at all except for control keys like enter,
escape, backspace.
When I run the same code on OSX,
c++ has gone too far with its templates...
On 12/30/2016 11:03 PM, Alexander Dyagilev wrote:
This does not work either:
std::unique_ptr var(
pointer, &QObject::deleteLater);
On 12/30/2016 10:58 PM, Alexander Dyagilev wrote:
On 12/30/2016 10:55 PM, Konstantin Tokarev wrote:
This does not work either:
std::unique_ptr var(
pointer, &QObject::deleteLater);
On 12/30/2016 10:58 PM, Alexander Dyagilev wrote:
On 12/30/2016 10:55 PM, Konstantin Tokarev wrote:
30.12.2016, 22:45, "Alexander Dyagilev" :
QScopedPointer var(new QObject, &QObject::deleteLat
On 12/30/2016 10:55 PM, Konstantin Tokarev wrote:
30.12.2016, 22:45, "Alexander Dyagilev" :
QScopedPointer var(new QObject, &QObject::deleteLater) - compiles fine.
std::unique_ptr var(new QObject, &QObject::deleteLater) - does not compile.
Is there an easy way I miss?
std::mem_fun(&QObject:
30.12.2016, 22:45, "Alexander Dyagilev" :
> QScopedPointer var(new QObject, &QObject::deleteLater) - compiles fine.
>
> std::unique_ptr var(new QObject, &QObject::deleteLater) - does not compile.
>
> Is there an easy way I miss?
std::mem_fun(&QObject::deleteLater) should work
>
> On 12/30/2016
Sorry, my bad.
QScopedPointer does not compiles so also...
On 12/30/2016 10:44 PM, Alexander Dyagilev wrote:
QScopedPointer var(new QObject, &QObject::deleteLater) - compiles fine.
std::unique_ptr var(new QObject, &QObject::deleteLater) - does not
compile.
Is there an easy way I miss?
On
QScopedPointer var(new QObject, &QObject::deleteLater) - compiles fine.
std::unique_ptr var(new QObject, &QObject::deleteLater) - does not compile.
Is there an easy way I miss?
On 12/30/2016 10:35 PM, Giuseppe D'Angelo wrote:
Il 30/12/2016 20:32, Alexander Dyagilev ha scritto:
This requires
Il 30/12/2016 20:32, Alexander Dyagilev ha scritto:
> This requires me to implement a special deleter function somewhere. I'm
> too lazy :)
>
> QPointer is a more convenient way.
QPointer would still require you to define your custom deleter (as
by default it would delete via operator de
This requires me to implement a special deleter function somewhere. I'm
too lazy :)
QPointer is a more convenient way.
On 12/30/2016 10:31 PM, Giuseppe D'Angelo wrote:
Il 30/12/2016 20:27, Alexander Dyagilev ha scritto:
Hmmm So there is not std::unique_ptr analogue in Qt?
And we hav
30.12.2016, 22:31, "Alexander Dyagilev" :
> Another, i think a better idea:
>
> Just rename QScopedPointer to QUniquePointer.
Just use std::unique_ptr<>
>
> THEN:
>
> 1. class QScopedPointer : public QUniquePointer {}
>
> 2. in this new QScopedPointer class forbid all the move semantics.
>
> I
Il 30/12/2016 20:27, Alexander Dyagilev ha scritto:
> Hmmm So there is not std::unique_ptr analogue in Qt?
>
> And we have to use std::unique_ptr with a special deleter...
>
> (I would like to use &QObjet::deleteLater one).
>
> Sadly...
>
But if you have C++11 (because all of this requires
Another, i think a better idea:
Just rename QScopedPointer to QUniquePointer.
THEN:
1. class QScopedPointer : public QUniquePointer {}
2. in this new QScopedPointer class forbid all the move semantics.
Isn't it a brilliant idea? :)
On 12/30/2016 10:27 PM, Alexander Dyagilev wrote:
Hmmm.
Hmmm So there is not std::unique_ptr analogue in Qt?
And we have to use std::unique_ptr with a special deleter...
(I would like to use &QObjet::deleteLater one).
Sadly...
Why don't you just introduce another class with another name that do
support?
E.g. QUniquePointer : public QScopedPo
Il 30/12/2016 19:47, Alexander Dyagilev ha scritto:
> Hello,
>
> https://bugreports.qt.io/browse/QTBUG-29754
>
> states that the problem was fixed and QScopedPointer supports it now.
>
I implemented it in 5b9006bbdba7dcab01b8e640554a7d7a4b64f76b, but then a
discussion on the mailing list caused
Hello,
https://bugreports.qt.io/browse/QTBUG-29754
states that the problem was fixed and QScopedPointer supports it now.
But it does not.
std::move does not compile.
error: C2248:
'QScopedPointer>::QScopedPointer':
cannot access private member declared in class
'QScopedPointer>'
with
[
T=W
Em sexta-feira, 30 de dezembro de 2016, às 19:13:58 BRST, Igor Mironchik
escreveu:
> Hello,
>
> I do app that uses USB camera. And I found that this app uses very much
> CPU time. Profiler says that:
>
> AMGetErrorTextW8.82s11.22s38.74%49.28% quartz
> [unknown]00x5ded687f
On Thu, Dec 29, 2016 at 5:26 PM, Jason H wrote:
> I've been looking into this recently, and the industry is converting on
> async/await keywords.
> They (and generators, coroutines, etc) are in ECMAScript 7 (babel
> supported), Python 3.5 (with complete support in 3.6) I consider generators
> as
Hello,
I do app that uses USB camera. And I found that this app uses very much
CPU time. Profiler says that:
AMGetErrorTextW8.82s11.22s38.74%49.28% quartz
[unknown]00x5ded687f
MsgWaitForMultipleObjectsEx6.62s6.62s29.08% 29.09%
USER32[unknown]
Em sexta-feira, 30 de dezembro de 2016, às 15:03:43 BRST, Giuseppe D'Angelo
escreveu:
> > Yes, using a custom allocator is possible.
> > But this another case where Qt succeeds in its philosohphy of easing
> > programming.
> Side note: did we bring forward this feature of QVector to the
> Standard
Il 30/12/2016 14:03, Philippe ha scritto:
> What is the logic of the C++ standard to introduce a new keyword (alignas)
> and have default containers ignoring them?...
There is no good reason, that's why this has been changed in C++17.
The language and the standard library evolve and these mistak
On Fri, Dec 30, 2016 at 2:03 PM, Philippe wrote:
>
> But this another case where Qt succeeds in its philosohphy of easing
> programming.
Well, I'm pretty sure that the goal of the standard C++ commitee is not to
produce something "easy", but something extensible and adaptable to the
most divers
Em sexta-feira, 30 de dezembro de 2016, às 14:03:57 BRST, Philippe escreveu:
> > Il 29/12/2016 13:03, Thiago Macieira ha scritto:
> > > How is it ia win for std::vector to achieve next year what QVector has
> > > done
> > > for the past 7 or 8?
> >
> > Because with std::vector it has been possible
2016-12-30 13:59 GMT+01:00 Elvis Stansvik :
> Hi all,
>
> Here's a minimal test case (run with qmlscene):
>
> import QtQuick 2.4
> import QtQuick.Window 2.2
>
> ListView {
> width: 300
> height: 300
> model: 10
> focus: true
> header: Rectangle {
> z: 2
> width:
> Il 29/12/2016 13:03, Thiago Macieira ha scritto:
> > How is it ia win for std::vector to achieve next year what QVector has done
> > for the past 7 or 8?
>
> Because with std::vector it has been possible for the last 16 years (by
> using a custom allocator), _and_ this behaviour has been well-d
Hi all,
Here's a minimal test case (run with qmlscene):
import QtQuick 2.4
import QtQuick.Window 2.2
ListView {
width: 300
height: 300
model: 10
focus: true
header: Rectangle {
z: 2
width: parent.width
height: 100
Text {
text: "Head
Em sexta-feira, 30 de dezembro de 2016, às 09:49:11 BRST, Thiago Macieira
escreveu:
> > > And yet that's the only accepted, official way for qmake.
> >
> > So how does this work for regular users on a system where they can't
> > modify
> > the mkspecs files?
>
> They don't change compiler flags.
Em sexta-feira, 30 de dezembro de 2016, às 11:45:22 BRST, Giuseppe D'Angelo
escreveu:
> Il 29/12/2016 13:03, Thiago Macieira ha scritto:
> > How is it ia win for std::vector to achieve next year what QVector has
> > done
> > for the past 7 or 8?
>
> Because with std::vector it has been possible f
Em sexta-feira, 30 de dezembro de 2016, às 00:59:31 BRST, René J. V. Bertin
escreveu:
> Thiago Macieira wrote:
> > And yet that's the only accepted, official way for qmake.
>
> So how does this work for regular users on a system where they can't modify
> the mkspecs files?
They don't change comp
Em sexta-feira, 30 de dezembro de 2016, às 11:29:11 BRST, Philippe escreveu:
> > How is it ia win for std::vector to achieve next year what QVector has
> > done
> > for the past 7 or 8?
>
> Not to mention we are likely far away from the time C++17 becomes a
> requirement to use or build Qt.
But t
Il 30/12/2016 11:29, Philippe ha scritto:
> Not to mention we are likely far away from the time C++17 becomes a
> requirement to use or build Qt.
But what prevents *you* from using C++17 in your projects right now?
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engine
Il 29/12/2016 13:03, Thiago Macieira ha scritto:
> How is it ia win for std::vector to achieve next year what QVector has done
> for the past 7 or 8?
Because with std::vector it has been possible for the last 16 years (by
using a custom allocator), _and_ this behaviour has been well-defined by
a
30.12.2016, 13:29, "Philippe" :
>> How is it ia win for std::vector to achieve next year what QVector has done
>> for the past 7 or 8?
>
> Not to mention we are likely far away from the time C++17 becomes a
> requirement to use or build Qt.
To be fair, nothing prevents anyone from starting usi
> How is it ia win for std::vector to achieve next year what QVector has done
> for the past 7 or 8?
Not to mention we are likely far away from the time C++17 becomes a
requirement to use or build Qt.
Philippe
On Thu, 29 Dec 2016 10:03:03 -0200
Thiago Macieira wrote:
> Em quinta-feira, 29 de
Hi,
I use Qt Purchasing to manage purchases on all my apps (iOS and Android).
Since I have upgraded to Qt 5.7 and 5.7.1 I’m having problems with it,
specially with Android.
I have only realised the dimension of this problem when I started logging
purchases failed. The most relevant error is
35 matches
Mail list logo
