[Development] Lack of base classes/interfaces? Q*, Q*F

André Somers andre at familiesomers.nl
Mon Apr 17 15:17:55 CEST 2017



Op 17/04/2017 om 12:31 schreef André Pönitz:
> On Mon, Apr 17, 2017 at 08:10:28AM +0200, André Somers wrote:
>>
>>> You're right I don't know how C++ handles virtuals, but should I
>>> care? This is OOP, I want to use OOP. You're telling me that because
>>> the language/compiler implements something poorly, that I can't use
>>> OOP?
>> There are many people for who real-world performance means a lot more
>> that your wish to use "OOP" - for whatever understanding you have of
>> that concept. Still, I'd like to see your proposal to to consolidate
>> QRect and QRectF into one hierarchy using that.
> I don't really see this happen, either, but one thing that could be
> done is to make the implementations of QRect and QRectF more similar
> (and having the QRect version generate less code for typical operations)
> by shifting the values stored in the x2 and y2 members by one, i.e.
> start with
>
>  -    Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(-1), y2(-1) {}
>  +    Q_DECL_CONSTEXPR QRect() Q_DECL_NOTHROW : x1(0), y1(0), x2(0), y2(0) {}
>
> and go from there.
>
> It's a bit less straightforward than it might appear as there are
> various related tests that practically test only the behaviour of
> (undefined, *cough*) signed integer overflow, but to me it looks
> like a harmless microoptimization in that area.
Well, that's mostly just implementation details. What I am more curious
for is how Jason proposes to hande the differences in return value types
between QRect and QRectF's methods. After all, the former returns int
for things like x, y, width and height, while the latter returns qreal...

André




More information about the Development mailing list