[Development] Move ctors for q_declare_shared types

[Marc Mutz]

On Friday 26 June 2015 22:52:17 Thiago Macieira wrote:
> On Friday 26 June 2015 10:45:24 Marc Mutz wrote:
[...]
> For example: can we make the deallocation function a member of the
> front-end class, which is usually exported anyway?

We can, at the expense of an additional template argument on QtP::SDP, but 
seeing as I'd like to unexport most, if not all, value classes, for the resons 
repeated many times on the list and in reviews, that won't help with the 
exporting.

> This would avoid the
> ugly need for two macros in a row like:
> 
> 	Q_GUI_EXPORT Q_SHAREDDATAPOINTER_DECLARE_DTOR(QFontPrivate);
> 
> Wouldn't the fact that it's a member function remove the need for the
> declaration prior to the class instantiation?

Maybe. I'll try.

> We may need a macro anyway, which I'd advise be called
> Q_DECLARE_PUBLIC_SHARED(ClassName)

What should hide behind that macro? Given a user-supplied swap, we can 
generate the move assignment operators from there, but not the move 
constructors (in case of more data fields, e.g. in QFont, QPalette 
(resolve_mask).

> > Mid-term goal would be to have all implicitly-shared classes use the same
> > smart pointer, be nothrow move-assignable, nothrow move-constructible,
> > and nothrow *default-constructible* (which requires a trick a la QRegion
> > / QString / QVector / QList (QtPrivate::RefCount and a shared null
> > state, or else a nullptr d-pointer)), probably by Qt 5.7.
> 
> Some of those classes are bigger than one pointer and/or may hold more than
> one pointer (for example, QSharedPointer).

But QSP is already nothrow default-constructible... What's the point you're 
trying to make?

> I've been playing with null d pointers for the past 3 years and I've never
> made it work and I wasn't even trying to keep BC.

Many classes happily use d == nullptr for their partially formed, sometimes 
even for their default-constructed state (QTimeZone, e.g.), even though 
drawing the line is hard in Qt classes, due to lack of documentation on the 
issue. QTimeZone checks d for nullptr in every member function, making it a 
valid state (as opposed to a partially-formed one).

But I was more thinking about shared_empty, though that looks to be 
complicated. At least the way QRegion does is is flawed (it uses double 
indirection, and *still* creates a QVector<> in a dynamically-initialised 
static-duration object. I wonder why Sérgio hasn't found that one yet...).

I experimented with QDateTimePrivate, which is simpler, but has a QTimeZone 
member. Replacing that one with QTimeZonePrivate*, QSD inheritance with 
QtP::RC aggregation and managing the QTZPrivate* ref-count manually should 
work, though I stopped to watch GER-FRA and USA-PRC yesterday before coming 
anywhere near completion. So probably too much work for all but the most 
central classes.

These pimpls start to create a lot of additional work. One more reason to 
reduce their use in value classes in the future, and esp. come Qt 6.

[...]

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts