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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
