Hi,
Thiago Macieira schrieb am Fr. 17. Juli 2020 um
19:57:
> On Wednesday, 15 July 2020 13:20:33 PDT Thiago Macieira wrote:
> > In addition, I'd like someone to explain here:
> [snip]
>
> 5) How you're going to fix the UB in the code generated by moc. This
> requires
> a satisfactory answer of C
> On 17 Jul 2020, at 14:28, Giuseppe D'Angelo via Development
> wrote:
>
> Il 17/07/20 14:09, Ulf Hermann ha scritto:
QAction *action = ~~~;
auto prop = action->text;
>> This already gives you the string. You cannot retrieve the property
>> itself. You can alternatively do action->te
I must be missing something. I tend to think of eventloops with notify
signals are an improvement over polling. You statement seems to say
that asking for a value is better, and notifications are to be avoided?
I'm not saying that you should go back to polling. In the case that you
have genu
Mhh, it there are no change signals anymore, i guess i also can't use
QObject::connect() anymore and rather use a binding instead ? This is
fine, but if two objects are living in different threads how does it
work then ? With a Queued connection how it works with signals/slots is
pretty clear, but
Am 17.07.20 um 19:12 schrieb Ulf Hermann:
>>> I've added a section to this one. Feel free to amend. However, newly
>>> designing APIs with QProperty is a different thing than converting old
>>> APIs in a compatible way.
>>
>> The complexity behind the scenes for us to support it is our problem,
>>
On Wednesday, 15 July 2020 13:20:33 PDT Thiago Macieira wrote:
> In addition, I'd like someone to explain here:
[snip]
5) How you're going to fix the UB in the code generated by moc. This requires
a satisfactory answer of C++17 or C++2a strictly compliant code, or we'll have
to stop using this f
On Friday, 17 July 2020 09:56:39 PDT Giuseppe D'Angelo via Development wrote:
> Il 17/07/20 17:30, Thiago Macieira ha scritto:
> > I will give a +2 for this patch, since I prefer it. That means adding
> > properties doesn't imply an extra 8 bytes per class in the hierarchy.
> > Imagine a user class
However, for Q_GADGET this would fall apart.
Actually, with a Q_GADGET you usually don't have a private object.
That's the whole point of it. Then you don't need property wrappers, either.
So, to confine the property wrapper to the QObject it belongs to we can
delete the copy and move construc
On Friday, 17 July 2020 09:41:16 PDT Lars Knoll wrote:
> > Let's say we're going to enable it now for Linux. Ok, good. Please make
> > EVERY SINGLE Qt build and user's application build unconditionally use
> > [[no_unique_address]] from now until 2028. Regardless of compiler choice
> > (GCC, Clang
I've added a section to this one. Feel free to amend. However, newly
designing APIs with QProperty is a different thing than converting old
APIs in a compatible way.
The complexity behind the scenes for us to support it is our problem, users
shouldn't care.
They will only care that the code the
On 17/07/20 19:00, Thiago Macieira wrote:
On Friday, 17 July 2020 09:34:54 PDT Lars Knoll wrote:
I'll just post this and let you ponder the consequences of this choice for
Linux:
https://godbolt.org/z/nhex5x
Yes, that’s why we need to encode that into a static_assert(). But the
support it comi
On Friday, 17 July 2020 09:34:54 PDT Lars Knoll wrote:
> > I'll just post this and let you ponder the consequences of this choice for
> > Linux:
> > https://godbolt.org/z/nhex5x
>
> Yes, that’s why we need to encode that into a static_assert(). But the
> support it coming to all compilers and Linu
> On 17 Jul 2020, at 15:01, Ulf Hermann wrote:
>
> QAction *action = ~~~;
> auto prop = action->text;
>>> This already gives you the string. You cannot retrieve the property
>>> itself. You can alternatively do action->text() or action->text.value().
>>> They all do the same thing.
>> Uhm
Il 17/07/20 17:30, Thiago Macieira ha scritto:
I will give a +2 for this patch, since I prefer it. That means adding
properties doesn't imply an extra 8 bytes per class in the hierarchy. Imagine
a user class hierarcy like QSctpSocket -> QTcpSocket -> QAbstractSocket ->
QIODevice -> QObject. If ea
> On 17 Jul 2020, at 17:30, Thiago Macieira wrote:
>
> On Friday, 17 July 2020 00:25:04 PDT Lars Knoll wrote:
>> Yes, it can and it does work. And it’s what we should be doing on compilers
>> that support [[no_unique_address]].
>
> The problem is that you can't change your mind, since it affects
> On 17 Jul 2020, at 17:50, Thiago Macieira wrote:
>
> On Friday, 17 July 2020 02:05:48 PDT Lars Knoll wrote:
>> Some older embedded toolchains don’t have the flag neither.
>
> Then give them an option to opt out, at Qt configure time. That's a flag on
> the same level as using -mfloat-abi=sof
On Friday, 17 July 2020 04:59:12 PDT Ulf Hermann wrote:
> > Quite a few wiki pages could do with an update: most obviously:
> > https://wiki.qt.io/API_Design_Principles
>
> I've added a section to this one. Feel free to amend. However, newly
> designing APIs with QProperty is a different thing tha
On Friday, 17 July 2020 04:54:08 PDT Giuseppe D'Angelo via Development wrote:
> Il 16/07/20 17:40, Volker Hilsheimer ha scritto:
> > The struct has no data itself, so ideally would be of size zero.
>
> I'm missing some piece of the puzzle: if you take action->text, and text
> is a zero-size struct
On Friday, 17 July 2020 00:25:04 PDT Lars Knoll wrote:
> Yes, it can and it does work. And it’s what we should be doing on compilers
> that support [[no_unique_address]].
The problem is that you can't change your mind, since it affects binary
compatibility. See https://godbolt.org/z/oExfzP:
str
On Friday, 17 July 2020 02:05:48 PDT Lars Knoll wrote:
> Some older embedded toolchains don’t have the flag neither.
Then give them an option to opt out, at Qt configure time. That's a flag on
the same level as using -mfloat-abi=softfp instead of -mfloat-abi=hard or
using -stdlib=libc++ for Clan
Il 17/07/20 11:36, Lars Knoll ha scritto:
And it’s cleaner, because using the union trick, we do access several members
of the union at the same time. It works on all compilers but I’m not 100%
convinced it’s fully defined behavior according to C++, even if the members
don’t have data.
To me
Hi Ulf,
> QProperty's main feature is accepting lazily evaluated bindings in place
of a plain value. It can also notify eagerly if you use the subscribe()
and onValueChanged() methods, but you'd usually avoid that as best as
you can.
I must be missing something. I tend to think of eventloops wi
QAction *action = ~~~;
auto prop = action->text;
This already gives you the string. You cannot retrieve the property
itself. You can alternatively do action->text() or action->text.value().
They all do the same thing.
Uhm... sorry, no, this doesn't really compute for me. Ignore the copy
semant
item->width.setBinding([]() { return otherItem->height(); });
...
item->widthSetBinding([]() { return otherItem->height(); });
...
See the definition of Q_PRIVATE_QPROPERTY for the different methods we
generate into the structs.
It sounds like there are two overlapping elements to these chan
Il 17/07/20 14:09, Ulf Hermann ha scritto:
QAction *action = ~~~;
auto prop = action->text;
This already gives you the string. You cannot retrieve the property
itself. You can alternatively do action->text() or action->text.value().
They all do the same thing.
Uhm... sorry, no, this doesn't re
> We are not casting these structs to or from anything though, do we?
...
>const auto *thisPtr = reinterpret_cast(reinterpret_cast(this) -
propertyMemberOffset);
sounds pretty much like the structs are indeed being casted to / from
anything <_<
On Fri, Jul 17, 2020 at 2:13 PM Ulf Hermann
Hi,
> item->width.setBinding([]() { return otherItem->height(); });
...
> item->widthSetBinding([]() { return otherItem->height(); });
...
> See the definition of Q_PRIVATE_QPROPERTY for the different methods we
generate into the structs.
It sounds like there are two overlapping elements to these
The struct has no data itself, so ideally would be of size zero.
I'm missing some piece of the puzzle: if you take action->text, and text
is a zero-size struct, how does the operator() applied to it figure out
which action needs to read the text property from? E.g. like so:
QAction *action
Quite a few wiki pages could do with an update: most obviously:
https://wiki.qt.io/API_Design_Principles
I've added a section to this one. Feel free to amend. However, newly
designing APIs with QProperty is a different thing than converting old
APIs in a compatible way.
__
Il 16/07/20 17:40, Volker Hilsheimer ha scritto:
The struct has no data itself, so ideally would be of size zero.
I'm missing some piece of the puzzle: if you take action->text, and text
is a zero-size struct, how does the operator() applied to it figure out
which action needs to read the tex
if it's all "fake" anyway, what exactly is the point of having that
struct in the first place? is it just to have an "anchor" in the
pre-processed code / AST?
The idea is that you can use the same name as getter and for
assignment/binding/subscribe etc:
something = item->width();
item->width
On Thu, Jul 16, 2020 at 03:40:35PM +, Volker Hilsheimer wrote:
The struct has no data itself, so ideally would be of size zero. The
moc-implementation redirects to whatever is passed into the
Q_PRIVATE_QPROPERTY macro [...]
if it's all "fake" anyway, what exactly is the point of having tha
Hello,
having used QtQuick professionally for serveral years now, I have some
suggestions regarding the text handling in Qt Quick.
One major point of interest for me is rich text handling. A large number of
modern (mostly HTML/Electron-based) applications nowadays feature smart text
input fie
> On 17 Jul 2020, at 11:25, Giuseppe D'Angelo via Development
> wrote:
>
> Il 17/07/20 11:05, Lars Knoll ha scritto:
>>> No, we should just static_assert for [[no_unique_address]] being available
>>> on the platforms where we expect it. That is, anywhere but on certain MSVCs.
>> Some older e
Il 17/07/20 11:05, Lars Knoll ha scritto:
No, we should just static_assert for [[no_unique_address]] being available on
the platforms where we expect it. That is, anywhere but on certain MSVCs.
Some older embedded toolchains don’t have the flag neither.
If we make it a configure feature, we op
> On 17 Jul 2020, at 10:47, Ulf Hermann wrote:
>
>
>>
>> Would it be sensible to make this a configure feature: if C++20 is
>> explicitly enabled, use it? It’s in the standard after all.
>> But auto-detecting it is perhaps unnecessarily fragile.
>
> No, we should just static_assert for [[n
Would it be sensible to make this a configure feature: if C++20 is explicitly
enabled, use it? It’s in the standard after all.
But auto-detecting it is perhaps unnecessarily fragile.
No, we should just static_assert for [[no_unique_address]] being
available on the platforms where we expect it.
> On 17 Jul 2020, at 09:34, Jean-Michaël Celerier
> wrote:
>
> It does work "in practice", but from the answer I got on SO, it's still
> technically UB.
> If anyone wants to add another, more positive answer sourced from the
> standard though it'd be very welcome :)
>
> https://stackoverflow.
> On 17 Jul 2020, at 09:25, Lars Knoll wrote:
>
>> On 16 Jul 2020, at 23:35, Thiago Macieira wrote:
>>
>> On Thursday, 16 July 2020 13:16:41 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
For pre-C++20 (where it’s possible to have zer
It does work "in practice", but from the answer I got on SO, it's still
technically UB.
If anyone wants to add another, more positive answer sourced from the
standard though it'd be very welcome :)
https://stackoverflow.com/questions/57823192/does-casting-an-empty-base-class-optimized-object-to-an
> On 16 Jul 2020, at 23:35, Thiago Macieira wrote:
>
> On Thursday, 16 July 2020 13:16:41 PDT Giuseppe D'Angelo via Development
> wrote:
>> Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
>>> For pre-C++20 (where it’s possible to have zero-size structs), and for
>>> compilers that don’t resp
41 matches
Mail list logo
