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 &bar() {
Q_D(Foo);
return d->bar;
}
};
struct FooPrivate {
QProperty bar;
};
Sure, propert
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 th
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(
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 8
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 assumin
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 connectio
