On 29.10.25 16:47, Volker Hilsheimer via Development wrote:
> And QParentedPointer as discussed so far has no knowledge of what “this”
> (or generally the parent) would be. Putting that information in there
> makes things overly complicated very clumsy to refactor (you’d end up
> maintaining a separate parent/child relationship in those pointers). In
> my mind, QParentedPointer’s only purpose is to make it explicit in code
> that the held object is expected to have a parent by the time the
> QParentedPointer variable goes out of scope; that expectation can be
> asserted via a Q_ASSERT in the destructor. Anything beyond that seems
> overkill.
I wouldn't even assert in the destructor. That will fire already when
these things are held as member functions in the "wrong" order.
Like gsl::owner, I would imagine that this would be all that's needed:
template using QParentedPointer = T*.
And then solve by human eyes or Clazy/clang-tidy.
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
