> we should avoid lazy initialisation This is a bit of a non answer tbh. Like yes, should is fine and all but when the developers are weighing in about optimising something using a static object to avoid unnecessary construction, what is the correct procedure to approach? Clearly the documentation doesn't have the required info. Nor does it guarantee that if we read the sources and establish that the code must be safe as is, that it will stay safe, since such guarantee was never given.
Do we just just read the docs literally and pessimize everything with thread_locals? Including QRegularExpression because its docs don't give us a go about static'ing it.... This sounds both the only 100% correct way and quite a bit sad at the same time in the absence of any guarantees in the documentation. On Sat, Jul 18, 2026 at 8:42 PM Thiago Macieira <[email protected]> wrote: > On Saturday, 18 July 2026 02:54:42 Pacific Daylight Time NIkolai Marchenko > wrote: > > Case in point QCollator::compare which seemingly does unprotected lazy > > initialization inside a const function. It may be a bug but even Giuseppe > > had stated that Qt doesn't guarantee such use case and exceptions are > > possible here and there despite it "generally" being safe. > > Strictly speaking, Giuseppe is right. But given the principle of least > surprise, we should avoid lazy initialisation in value-type classes > precisely > because people assume they can call const methods from multiple threads. > Lazy > initialisation in object-type classes is usually fine. > > If the class is using a smart pointer for the Private, the smart pointer > will > propagate the constness of the public function and it will be easy to > notice > where we violate by way of a const_cast. Older classes often use raw > pointers, > which don't propagate const, and then we may perform non-const operations, > intentionally or not. > > QCollator is not only a raw pointer, it's a mutable one at that. Looking > at > the implementation and logs, we've had bugs with that - see > 199c49517e184db09cbb5eff60e15d73096b330b from 5.11 for example. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Principal Engineer - Intel DCG - Platform & Sys. Eng. > -- > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development >
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
