>> We should also move Qt smart pointers to Qt5Compat module. The destiny >> of QPointer is not well defined so far. > This was not part of the research and should probably discussed separately. I agree. But if we decide using standard smart pointers, why should we keep Qt smart pointers as a part of Qt6? It would be a duplication in this case. I thought that it is just a logical consequence.
On 2/12/20 11:57 AM, Karsten Heimrich wrote: > Many thanks Vitaly for taking the time and effort to get the discussion going. > > -----Original Message----- >> From: Development<development-boun...@qt-project.org> On Behalf Of Vitaly >> Fanaskov >> Sent: Dienstag, 11. Februar 2020 16:15 Uhr >> To: development @qt-project.org >> Subject: Re: [Development] The future of smart pointers in Qt API >> >> I want to summarize intermediate results of the discussion and return it >> back to the track. >> >> >> Subject: using smart pointers in the API. >> Good idea.Better to use than not because of automatic lifetime >> management, explicit ownership semantics, and code base maintainability >> is simpler.However, it doesn’t mean that this is a mandatory choice for >> all API, just a recommended way so far. > If the outcome of this discussion is to not use/ introduce smarter pointers > in our public API's right now, it's still worth considering an update to our > API design principles for new modules. > >> Subject: standard smart pointers vs. Qtish wrappers. >> In general, people want to use standard smart pointers.There are a few >> main reasons: std-things are already in Qt API, this is a part of C++ >> language standard, it requires almost no maintainability, people outside >> of Qt ecosystem most likely get used to standard smart pointers for nine >> years. > I can only second that, we should not invent our own wrappers around std:: > smart pointers just for the shake of typography. > >> We should also move Qt smart pointers to Qt5Compat module. The destiny >> of QPointer is not well defined so far. > This was not part of the research and should probably discussed separately. > >> Subject: raw pointers for passing mandatory parameters vs. using >> references. >> Allow both approaches, recommend using references (and/or smart >> pointers) when acceptable. Not too many arguments collected here, just >> try to make Qt API more modern. > I think because most of the discussion has been centered around the use of > smart pointers in widgets/layouts/ui centric stuff, we might have lost view > on the way more generic uses of raw pointers in our API. Some of our classes > return raw pointers (QModbusReply and things like that come to my mind), > where ownership is not clear/ now well documented/ not documented at all; and > I can clearly see said API's benefit of the introduction of smart pointers. > >> There are a few irrelevant discussions. Start a new thread if you want >> to continue discussing them, please. >> >> >> Irrelevant subject: smart pointers vs.parent-child lifetime management >> model. >> It’s too fragile to touch in Qt6.Adding smart pointers around is >> questionable solution, it’s unclear whether it worth doing or not. >> Having two different but coupled mechanisms for lifetime management is >> not such a good idea. > True. We might not be able to address it for Qt6, but I think it's still > worth to keep in mind and re-question the current approach. Daniels patch > seems to be the best starting point so far. > > -- Karsten -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company / Qt Quick and Widgets Team _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
