[Development] unique_ptr and Qt, Take 2

[Konstantin Shegunov]

On Mon, May 6, 2019 at 10:42 AM Lars Knoll <lars.knoll at qt.io> wrote:

> Not sure whether it’s most projects, but there certainly are users doing
> it. And we’ve been using the pattern in our examples in some cases as well.
> But I can relate to Allan that creating widgets on the stack is bad style
> (as it conflicts with the way we memory manage them), and if I’d have a
> choice today, I would probably prefer to enforce them to be created on the
> heap by some means.
>

Fine, there seems to be somewhat of an argument in that regard. I'd raise
the question then, what should be done for QObject derived classes, and I
don't mean the ones that come from Qt (i.e. QFile, which Thiago mentioned),
but the ones the user defines. In the end QObject is for us to derive from
- get signals and slots and all those goodies. But then if one restricts
QObject to be on the heap how do we treat the user classes? What I mean is
- you can control how allocations happen in the library, say you provide
custom new/delete for QObject and/or QWidget and restrict the stack
(presumably through some trickery that disables the constructor), does this
mean we are to force the user to write their own allocation operators for
their classes? This doesn't really sound practical to say the least.
Moreover there's really little reason (from the user's point of view) to
have something in the heap if it can go on the stack. What do we do with
QCoreApplicaiton, force the heap on it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190506/9dd36ea2/attachment.html>