On Wed, 29 Oct 2025 at 18:41, Marc Mutz via Development <[email protected]> wrote: > > 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.
Maybe it should assert in a *constructor*, that it's given a non-null pointer that has a parent. > 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. I think that's a separate idea, with separate trade-offs. A smart pointer that isn't a pointer is far superior, because deleting it is ill-formed and doesn't need separate static analysis tools or runtime checks. -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
