[Development] Move ctors for q_declare_shared types

[Thiago Macieira]

On Saturday 27 June 2015 12:05:19 Marc Mutz wrote:
> 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.

I won't accept the unexporting if there are more than a handful of non-inline 
functions. MSVC be damned for having a crappy ABI, but we've survived 15 years 
like this, so it's not enough a reason to make the headers look uglier and 
slower to parse.

The right way to do this is the QList / QListData or the QVector / QArrayData 
split.

> > 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).

The declaration of the d pointer, the declaration of the maybe-deleter and 
possibly even the copy and move operators/constructors, all done the right 
way.

> > > 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?

Just that some of the classes you may be looking at aren't just a pointer.

In any case, QVector, QString and QByteArray's port to QArrayDataPointer 
should be finished, as intended during Qt 5.0 development.

> > 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).

I meant specifically QArrayData::shared_null being replaced by a null pointer 
instead.

> 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...).

Right.

> 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.

Agreed, which means the value classes' own size grows, which means QVariant 
should also grow to at least 4 * sizeof(void*).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center