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

André Pönitz apoenitz at t-online.de
Mon Apr 17 12:31:42 CEST 2017

On Mon, Apr 17, 2017 at 08:10:28AM +0200, André Somers wrote:
> Op 17/04/2017 om 08:02 schreef Jason H:
> > Maybe templates are the way to go. But I just had to change some
> > lines because I was using vectors and Qt was using QList. I'd like
> > to eliminate the need/cost for QList::toVector() and
> > QVector::toList(). If there was a base that provided the basics so
> > that I don't have to worry about it's representation in my code, I
> > want the developer (usually me, but anyone using my functions) to be
> > the one that makes that decision. 
> Well, I think most people here would agree QList was not the best
> choice in retrospect.
> >
> > 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.

> >> It wouldn't be easy for us either, as the algorithms are subtly
> >> different. The rectangle and size, for example, store the inclusive
> >> bottom-right coordinate, whereas the floating point ones store them
> >> exclusive.

... fixing that.


More information about the Development mailing list