On Friday, 24 July 2020 10:32:08 PDT Ville Voutilainen wrote:
> I don't know what the "sub-scope of a class" means.
struct S
{
namespace prop1 {
int operator()() const;
void bind(std::function binding;
};
private:
int propvalue;
}
int S::prop1::operator()() const
{
On Fri, 24 Jul 2020 at 22:24, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > A few years ago, Gtk threatened to do that starting with Gtk 4:
> > https://lwn.net/Articles/691131/
> > https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
> >
Hi!
With my Debian Qt maintainer hat on: I want to stress everything that
Thiago mentioned in the cited below mail. Rebuilding the entire Qt
world in a distribution is a tremendous huge task. I'm afraid I can't
express the pain it is specially for libraries as popular as Qt... try
it yourself
On Fri, 24 Jul 2020 at 18:10, Thiago Macieira wrote:
> Can I suggest that we prepare at least two papers for the standard? One for
> the member-to-containing-object trick and the second for what QProperty really
> is: sub-scope of a class. We don't want a different this pointer, we just want
>
On Friday, 24 July 2020 08:27:54 PDT Stottlemyer, Brett (B.S.) wrote:
> ... what QProperty really
> is: sub-scope of a class. We don't want a different this pointer, we
> just want to scope.
>
> Is QProperty really a sub-scope? Many of the examples are not tied to
> objects (QObject or
On 7/24/20, 11:09 AM, "Development on behalf of Thiago Macieira"
wrote:
... what QProperty really
is: sub-scope of a class. We don't want a different this pointer, we just
want
to scope.
Is QProperty really a sub-scope? Many of the examples are not tied to objects
(QObject or
On Friday, 24 July 2020 00:20:46 PDT Olivier Goffart wrote:
> You do not need to use the empty array everywhere: only in the helper type
> created by the Q_PRIVATE_QPROPERTY macro. And it can be conditioned on
> pre-c++20 GCC.
The problem is that it is in QObject and other Qt classes. That's why
Yes. QNX 7.1 is based on GCC 8.
On 2020-07-23, 5:03 PM, "Development on behalf of Ville Voutilainen"
wrote:
On Thu, 23 Jul 2020 at 23:59, Thiago Macieira
wrote:
>
> On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > I think the primary environment where a
On 23/07/20 22:54, Thiago Macieira wrote:
On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
I think the primary environment where a transition and resulting BC
breakage would be annoying is the Linux system environment with gcc. This
is where Olivier’s solution is quite elegant IMO.
On Thursday, 23 July 2020 15:10:23 PDT Thiago Macieira wrote:
> Strictly speaking, drop GCC 8 for Linux. For other OSes where Qt is not a
> system library it could remain.
Correcting myself again: drop GCC 8 and Clang 8 (and all previous versions)
for Linux and the open source BSDs with a Ports
On Thursday, 23 July 2020 14:03:54 PDT Ville Voutilainen wrote:
> > I'd rather go to [[no_unique_address]] instead of this. The extension
> > doesn't compile in all cases (you can't have a Flexible Array Member
> > everywhere) and is going to produce warnings.
> >
> > Let's just drop GCC 8.
>
>
On Thursday, 23 July 2020 08:33:39 PDT André Pönitz wrote:
> If Qt would bump major versions once a year, and take that as a chance to
> break BC, would that be a problem, if so, why?
Let's assume Qt remains strictly source compatible, not even by removing
deprecations. That means we can only do
On 2020-07-23 23:09, Ville Voutilainen wrote:
On Fri, 24 Jul 2020 at 00:03, Ville Voutilainen
wrote:
On Thu, 23 Jul 2020 at 23:59, Thiago Macieira wrote:
On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
I think the primary environment where a transition and resulting BC
breakage
On Thursday, 23 July 2020 13:50:26 PDT Bernhard Lindner wrote:
> I thought of something like a simple, manually maintained ABI version. Sure,
> on the one hand this wouldn't prevent uninentional BC breaks. On the other
> hand, BC changes could be done intentionally and managed in a safe way
>
On Fri, 24 Jul 2020 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 23 Jul 2020 at 23:59, Thiago Macieira
> wrote:
> >
> > On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > > I think the primary environment where a transition and resulting BC
> > > breakage would be annoying is
On Thu, 23 Jul 2020 at 23:59, Thiago Macieira wrote:
>
> On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> > I think the primary environment where a transition and resulting BC
> > breakage would be annoying is the Linux system environment with gcc. This
> > is where Olivier’s
On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote:
> I think the primary environment where a transition and resulting BC
> breakage would be annoying is the Linux system environment with gcc. This
> is where Olivier’s solution is quite elegant IMO.
I'd rather go to [[no_unique_address]]
> > Couldn't those subtle errors be replaced by some clear and understandable
> > error? Like some explicit binary compatibility check?
>
> Such a test does not exist, comprehensively. We can put a few common things
> in
> an ABI marker, like the size of QObject, the actual type qreal maps
Olivier Goffart schrieb am Fr. 17. Juli 2020 um 19:12:
> 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
> >>
>
On Wed, Jul 22, 2020 at 10:24:21AM -0700, Thiago Macieira wrote:
> On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> > How often do we think people are actively taking advantage of Qt's BC
> > promise (and how often do we hold this promise, and how often is this
> > relevant as we do
On Wednesday, 22 July 2020 14:17:26 PDT Bernhard Lindner wrote:
> Hi!
>
> > Breaking BC means subtle errors that are hard do detect and debug.
>
> Couldn't those subtle errors be replaced by some clear and understandable
> error? Like some explicit binary compatibility check?
Such a test does
Hi!
> Breaking BC means subtle errors that are hard do detect and debug.
Couldn't those subtle errors be replaced by some clear and understandable
error? Like some explicit binary compatibility check?
--
Best Regards,
Bernhard Lindner
___
On Wednesday, 22 July 2020 09:55:31 PDT André Pönitz wrote:
> How often do we think people are actively taking advantage of Qt's BC
> promise (and how often do we hold this promise, and how often is this
> relevant as we do not promise to change behaviour while keeping BC)?
That is a good
On Wed, Jul 22, 2020 at 10:27:14AM +, Lars Knoll wrote:
> > On 22 Jul 2020, at 11:38, Shawn Rutledge wrote:
> >
> >
> >> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
> >>
> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> >> actually late to the game. If we
On Wednesday, 22 July 2020 08:52:17 PDT Simon Hausmann wrote:
> > On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote:
> > > That said, this very construct that you're referring to, that is what
> > > has been in user
> > > code since QtDeclarative was been released [1]. Anybody using
> >
On Wednesday, 22 July 2020 08:50:50 PDT Lars Knoll wrote:
> I still don’t understand why you think this should be necessary. All we need
> to do is clearly document that enabling/disabling the support for this
> feature is not binary compatible and make sure users don’t mix by accident.
First, I
Thiago Macieira schrieb am Mi. 22. Juli 2020 um
17:46:
> On Wednesday, 22 July 2020 00:05:34 PDT Simon Hausmann wrote:
> > That said, this very construct that you're referring to, that is what
> > has been in user
> > code since QtDeclarative was been released [1]. Anybody using
> >
> On 22 Jul 2020, at 17:30, Thiago Macieira wrote:
>
> On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote:
>> no_unique_address is coming and making that problem go away. It’s available
>> on all compilers except MSVC today (see
>>
On Wednesday, 22 July 2020 03:24:30 PDT Lars Knoll wrote:
> no_unique_address is coming and making that problem go away. It’s available
> on all compilers except MSVC today (see
> https://en.cppreference.com/w/cpp/compiler_support#cpp2a).
>
> We want things to work on C++17 and that’s what we
On 16-07-2020 17:40, Volker Hilsheimer wrote:
We need “text” to be a public member of QAction, otherwise we can’t do
action->text();
That ‘text” member is a struct with a bunch of operators overloaded, so that we
can do either
qDebug() << action->text();
qDebug() << action->text;
and
> On 22 Jul 2020, at 11:38, Shawn Rutledge wrote:
>
>
>> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
>>
>> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
>> actually late to the game. If we want Qt to stay relevant, then it needs to
>> offer the same kind of
On 22 Jul 2020, at 00:14, Ville Voutilainen
mailto:ville.voutilai...@gmail.com>> wrote:
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer
mailto:volker.hilshei...@qt.io>> wrote:
With the current design, notational convenience doesn’t work either:
auto text = qAction->text;
text.left(10); // booh
> On 21 Jul 2020, at 22:51, Ville Voutilainen
> wrote:
>
> On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
> wrote:
>>
>> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira
>> wrote:
>>>
>>> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
A very significant goal of this
> On 2020 Jul 16, at 11:19, Ulf Hermann wrote:
>
> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> actually late to the game. If we want Qt to stay relevant, then it needs to
> offer the same kind of convenience and performance that other frameworks
> offer. This
On Tuesday, 21 July 2020 16:13:52 PDT Thiago Macieira wrote:
> The memcpys qualify under all of those conditions, with even explicit
> workarounds in the compilers. I don't see why you think qobject_cast has UB;
> did you mean qFindChildren?
I also want to make a distinction based on the
On Tuesday, 21 July 2020 14:18:15 PDT Volker Hilsheimer wrote:
> auto text = qAction->text;
> text.left(10); // booh
Just make the internal property helper type neither copyable nor movable.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
On Tuesday, 21 July 2020 13:51:11 PDT Ville Voutilainen wrote:
> See also all the memcpys that are done with types that are
> polymorphic, and the ones
> where we memcpy types that have user-provided copy operations. qtbase
> is UB left right
> and center, but it's certainly interesting that when
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer wrote:
> With the current design, notational convenience doesn’t work either:
>
> auto text = qAction->text;
> text.left(10); // booh
>
> ‘text’ is not a QString, but a QAction::_qt_property_api_text object, with
> broken... everythings.
>
>
> And
> On 21 Jul 2020, at 22:51, Ville Voutilainen
> wrote:
>
> On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
> wrote:
>>
>> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira
>> wrote:
>>>
>>> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
A very significant goal of this
On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
wrote:
>
> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira
> wrote:
> >
> > On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
> > > A very significant goal of this exercise is achieving notational
> > > convenience. Theoretical concerns
On Tue, 21 Jul 2020 at 22:12, Thiago Macieira wrote:
>
> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
> > A very significant goal of this exercise is achieving notational
> > convenience. Theoretical concerns about UB
> > in the presence of papers that apparently excise that UB
On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
> A very significant goal of this exercise is achieving notational
> convenience. Theoretical concerns about UB
> in the presence of papers that apparently excise that UB shouldn't
> stand in the way of that goal.
Sorry, I don't
On Tue, 21 Jul 2020 at 16:19, Volker Hilsheimer wrote:
> object->property = newValue;
>
>
> is not possible with this, but having to write
>
> object->setProperty(newValue);
>
> like we do today can’t be a blocker for the entire concept of bindable and
> lazily evaluted properties.
A very
> On 21 Jul 2020, at 16:27, Fabian Kosmale wrote:
>
> Sacrificing operator= to avoid UB and hacks is probably fine (though I expect
> some grumbling about the API). But would you suggest that "real"
> (non-pimpled) QProperties and "fake" (pimpled) properties have a different
> API?
Using
On Tuesday, 21 July 2020 07:27:11 PDT Fabian Kosmale wrote:
> Sacrificing operator= to avoid UB and hacks is probably fine (though I
> expect some grumbling about the API). But would you suggest that
> "real" (non-pimpled) QProperties and "fake" (pimpled) properties have a
> different API?
It
Sacrificing operator= to avoid UB and hacks is probably fine (though I
expect some grumbling about the API). But would you suggest that
"real" (non-pimpled) QProperties and "fake" (pimpled) properties have a
different API?
And would you change the the property design to always go through
> On 20 Jul 2020, at 20:30, Thiago Macieira wrote:
>
> On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote:
>> anyway, this can be trivially bypassed by just using an arbitrary
>> address and subtracting the offset. or using offsetof, indeed. in any
>> case it's 3 minutes of work.
>
On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote:
> anyway, this can be trivially bypassed by just using an arbitrary
> address and subtracting the offset. or using offsetof, indeed. in any
> case it's 3 minutes of work.
Sorry, an arbitrary address won't work either because it's
On Monday, 20 July 2020 11:06:36 PDT Giuseppe D'Angelo via Development wrote:
> Il 20/07/20 07:21, Thiago Macieira ha scritto:
> > ASM is not a solution. There's at least one major compiler (MSVC) that
> > doesn't allow any assembler.
>
> What do you mean, MSVC doesn't allow inline ASM?
Correct.
Il 20/07/20 07:21, Thiago Macieira ha scritto:
ASM is not a solution. There's at least one major compiler (MSVC) that doesn't
allow any assembler.
What do you mean, MSVC doesn't allow inline ASM?
I'm not proposing that the ASM itself needs to be emitted by moc, moc
could just call a function
On Monday, 20 July 2020 10:26:34 PDT Ville Voutilainen wrote:
> The only dispute in the offsetof article is about whether that
> indirection is UB in C. In C++ it is, and will remain so.
> That's why C++-compliant stddef.h implementations don't do that.
$ gcc -dM -E -include stddef.h -xc++
On Mon, 20 Jul 2020 at 19:09, Thiago Macieira wrote:
>
> On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote:
> > On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote:
> > >I am not going to accept a null-pointer dereference in there. The
> > >static_cast(nullptr)-> must go.
On Monday, 20 July 2020 08:40:06 PDT Oswald Buddenhagen wrote:
> On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote:
> >I am not going to accept a null-pointer dereference in there. The
> >static_cast(nullptr)-> must go.
>
> this this construct is actually UB is disputed on wikipedia
On Mon, Jul 20, 2020 at 07:32:41AM -0700, Thiago Macieira wrote:
I am not going to accept a null-pointer dereference in there. The
static_cast(nullptr)-> must go.
this this construct is actually UB is disputed on wikipedia (in the
offsetof article).
anyway, this can be trivially bypassed by
On Monday, 20 July 2020 01:23:39 PDT Lars Knoll wrote:
> But I don’t see why we would need to do this now, if the code we have works
> fine on current compilers. It’s all non inline, so we could add those kind
> of workarounds only if they become a requirement for a certain compiler.
It's
> From: Development on behalf of Ulf
> Hermann
>>> 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.
Just for clarification: actually you usually do
> On 20 Jul 2020, at 07:24, Thiago Macieira wrote:
>
> On Sunday, 19 July 2020 14:42:24 PDT Giuseppe D'Angelo via Development wrote:
>> * change /*2*/ to use ASM. We know the ABI of the platforms we support
>> and we know how to calculate the correct pointer value, we just need to
>> stop
On Sunday, 19 July 2020 14:42:24 PDT Giuseppe D'Angelo via Development wrote:
> * change /*2*/ to use ASM. We know the ABI of the platforms we support
> and we know how to calculate the correct pointer value, we just need to
> stop C/C++ from reason about it and flagging it as possible UB. Yes,
>
On 16-07-2020 13:08, Edward Welbourne 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 respect the [[no_unqiue_address]] attribute,
all these struct-instances are put into a union. In that case,
Il 19/07/20 20:42, Thiago Macieira ha scritto:
In that sense, Peppe's suggestion of C++17 offsetof is better.
To clarify, I was proposing to do something like this:
Type Klass::_qt_property_api_propertyName::value() const
{
/*1*/ const size_t propertyMemberOffset =
On Sun, 19 Jul 2020 at 21:52, Thiago Macieira wrote:
>
> On Sunday, 19 July 2020 08:20:01 PDT Thiago Macieira wrote:
> > 1. Revert the feature.
> > 2. Write papers to add necessary functionality to C++23, like reversing a
> >pointer-to-member-object back to the containing object
> > 3.
On Sunday, 19 July 2020 08:20:01 PDT Thiago Macieira wrote:
> 1. Revert the feature.
> 2. Write papers to add necessary functionality to C++23, like reversing a
>pointer-to-member-object back to the containing object
> 3. Require C++23 in Qt 7.0
>
> double
On Sunday, 19 July 2020 03:51:00 PDT Oswald Buddenhagen wrote:
> - the compiler becomes intentionally belligerent, in which case an
>override switch will be provided as well (if not instantly, then after
>the outcry that immediately follows)
Even if that were the case, we'd need
On Sun, 19 Jul 2020 at 15:25, Oswald Buddenhagen
wrote:
> (side effects of) actual optimizations are by definition not intentional
> belligerence. (one would, however, expect that entire chunks of code
> being thrown away would result in a warning that informs about
> specifically that (and not
On Sun, Jul 19, 2020 at 01:14:08PM +0200, Giuseppe D'Angelo via Development
wrote:
offsetof is conditionally-supported for non standard layout classes in
C++17.:
oh, good. that means that the second line should also keep working, as
that is semantically equivalent with offsetof being
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto:
- the compiler becomes intentionally belligerent, in which case an
override switch will be provided as well (if not instantly, then after
the outcry that immediately follows)
File under "surely no compiler will optimize away X!", for X
Il 19/07/20 12:51, Oswald Buddenhagen ha scritto:
- the compiler somehow starts to actually make use of the freedom
granted by the fact that QObject is not standard-layout (this, btw, is
also the reason why peppe's suggestion to use offsetof doesn't fix
UB).
offsetof is
On Sat, Jul 18, 2020 at 10:10:41AM -0700, Thiago Macieira wrote:
On Friday, 17 July 2020 23:32:41 PDT Simon Hausmann wrote:
This hack has been in QtQml in production since its release in 2010 (see
static cast selector).
It would be a shame if this stopped working
The problem here is the
On Sat, 18 Jul 2020 at 03:58, Ulf Hermann wrote:
>
> > 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
Il 18/07/20 12:08, Arno Rehn ha scritto:
Can't we just hide the QProperty behind a method call, like with an
ordinary getter method? E.g.
class Foo
{
// ...
QPropert () {
Q_D(Foo);
return d->bar;
}
};
struct FooPrivate {
QProperty bar;
};
Sure, property
On Friday, 17 July 2020 23:32:41 PDT Simon Hausmann wrote:
> This hack has been in QtQml in production since its release in 2010 (see
> static cast selector).
>
> It would be a shame if this stopped working
The problem here is the damage that can happen if a breakage happens. If the
QtQml code
On Saturday, 18 July 2020 07:11:51 PDT Giuseppe D'Angelo via Development
wrote:
> > auto prop = object->propertyName;
> > return prop.value();
>
> How? Just like QStringBuilder, there's no way to block a `const auto &`,
> is there?
A reference is ok. The problem is the copy or move, since now
Il 17/07/20 19:55, Thiago Macieira ha scritto:
moc generates:
Type Klass::_qt_property_api_propertyName::value() const
{
const size_t propertyMemberOffset =
reinterpret_cast(&(static_cast(nullptr)->propertyName));
const auto *thisPtr = reinterpret_cast(
Il 17/07/20 19:36, Thiago Macieira ha scritto:
So in your example QSctpSocket would still be 24 bytes, because the
inheritance is not deep enough to make sizeof 32?
Yes, with the IA-64 ABI, assuming we don't mandate [[no_unique_address]] of
course.
Still, is it worth breaking ABI for sparing
On 17/07/2020 19:30, Ulf Hermann wrote:
>> I am confused. Removing the struct means we’re back to a
>> setFoo()/foo() style API, and especially, we have a different API for
>> people using Property directly and what we provide in our public API.
>> That simply doesn’t make sense.
>
> I was
Am 17.07.20 um 21:35 schrieb Ulf Hermann:
>> 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
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
> 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
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
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,
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
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
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
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,
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
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
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
> 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.
>>
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
> 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
> 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
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
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
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:
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
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
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
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
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
1 - 100 of 143 matches
Mail list logo
