Re: [Development] unique_ptr and Qt, Take 2

The minor problem being that to not so small audiences, new Whoosh(something); just looks like a bug, and then you need to look three times to realize that something is a parent. Sure... but `something.createChild()` can help with that. OTOH, I just realized a problem with that... when the new

Re: [Development] unique_ptr and Qt, Take 2

On 15/06/2019 14.24, Ville Voutilainen wrote: > On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke > wrote: OTOH, I just realized a problem with that... when the new child needs to take its parent in the ctor for other reasons. I don't know if there is an easy solution to that. (Of cour

Re: [Development] unique_ptr and Qt, Take 2

On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke wrote: > >> OTOH, I just realized a problem with that... when the new child needs to > >> take its parent in the ctor for other reasons. I don't know if there is > >> an easy solution to that. (Of course, you can still pass the parent with > >> createC

Re: [Development] unique_ptr and Qt, Take 2

On 14/06/2019 17.05, Ville Voutilainen wrote: > On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke wrote: >> On 13/06/2019 16.09, Ville Voutilainen wrote: >>> The minor problem being that to not so small audiences, >>> new Whoosh(something); >>> just looks like a bug, and then you need to look three tim

Re: [Development] unique_ptr and Qt, Take 2

On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke wrote: > > On 13/06/2019 16.09, Ville Voutilainen wrote: > > The minor problem being that to not so small audiences, > > new Whoosh(something); > > just looks like a bug, and then you need to look three times to > > realize that something is a parent.

Re: [Development] unique_ptr and Qt, Take 2

Am 13.06.2019 um 23:44 schrieb Konstantin Tokarev: 14.06.2019, 00:14, "Christian Ehrlicher" : Am 13.06.2019 um 22:09 schrieb Ville Voutilainen:  That's one of the things I love about Qt; object hierarchies give me  working dynamic memory management without needing even smart pointers.  Tha

Re: [Development] unique_ptr and Qt, Take 2

14.06.2019, 00:14, "Christian Ehrlicher" : > Am 13.06.2019 um 22:09 schrieb Ville Voutilainen: >>>  That's one of the things I love about Qt; object hierarchies give me >>>  working dynamic memory management without needing even smart pointers. >>  That's the one thing that makes me queasy about

Re: [Development] unique_ptr and Qt, Take 2

On 13/06/2019 16.09, Ville Voutilainen wrote: > The minor problem being that to not so small audiences, > new Whoosh(something); > just looks like a bug, and then you need to look three times to > realize that something is a parent. Sure... but `something.createChild()` can help with that. OTOH,

Re: [Development] unique_ptr and Qt, Take 2

Am 13.06.2019 um 22:09 schrieb Ville Voutilainen: That's one of the things I love about Qt; object hierarchies give me working dynamic memory management without needing even smart pointers. That's the one thing that makes me queasy about using Qt in large applications; I always need to worry abo

Re: [Development] unique_ptr and Qt, Take 2

On June 13, 2019 17:25:15 Matthew Woehlke wrote: > On 13/06/2019 03.03, Marco Bubke wrote: >> On June 12, 2019 23:13:14 Matthew Woehlke wrote: me here. I think Daniel is on to something and we really should explore having smart pointers in Qt 6, but at this point I'm not convinced

Re: [Development] unique_ptr and Qt, Take 2

On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote: > > On 13/06/2019 14.13, Daniel Teske wrote: > > On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow > > three rules: - If you create an object > on the stack, either don't parent it or ensure>> its parent outlives

Re: [Development] unique_ptr and Qt, Take 2

> * enable templated QObjects. There's a prototype from Olivier, so is that > possible? Yes, this is long overdue. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/devel

Re: [Development] unique_ptr and Qt, Take 2

On 13/06/2019 14.13, Daniel Teske wrote: > On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow > three rules: - If you create an object on the stack, either don't parent it or ensure>> its parent outlives it. (Usually not hard!)>> - If you create an object with `new`,

Re: [Development] unique_ptr and Qt, Take 2

Hi, I was happly ignoring the other threads, since I didn't like the temperature of some the responses. But I guess you force me to write a response not just to you, but something that is a bit more general. Or... just don't do that? I can't recall that I've *ever* had problems with QObject

Re: [Development] unique_ptr and Qt, Take 2

On 13/06/2019 03.03, Marco Bubke wrote: > On June 12, 2019 23:13:14 Matthew Woehlke wrote: >>> me here. I think Daniel is on to something and we really should explore >>> having smart pointers in Qt 6, but at this point I'm not convinced >>> std::unique_ptr alone is it. I'd like to see what we cou

Re: [Development] unique_ptr and Qt, Take 2

On June 12, 2019 23:13:14 Matthew Woehlke wrote: >> me here. I think Daniel is on to something and we really should explore >> having smart pointers in Qt 6, but at this point I'm not convinced >> std::unique_ptr alone is it. I'd like to see what we could achieve with a >> QObject-specific smart p

Re: [Development] unique_ptr and Qt, Take 2

On 03/05/2019 15.13, Thiago Macieira wrote: > On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote: >> Anyhow, I too feel that we may need a dedicated smart pointer class for >> this, to catch all the corner cases and allow the existing flow of >> >> 1) create something >> 2)

Re: [Development] unique_ptr and Qt, Take 2

The patch I propose does not take that into account and is indeed almost entirely source compatible. Scratch the "not". And while I'd encourage someone to try it out, I'm of the firm opinion that Qt should try to get over its NIH attitude. One of the issues with Qt in the real world is th

Re: [Development] unique_ptr and Qt, Take 2

Am 06.05.2019 um 12:04 schrieb Lars Knoll: On 6 May 2019, at 10:27, Konstantin Shegunov > wrote: On Mon, May 6, 2019 at 10:42 AM Lars Knoll > wrote: Not sure whether it’s most projects, but there certainly are users doing it. And

Re: [Development] unique_ptr and Qt, Take 2

04.05.2019, 02:16, "Иван Комиссаров" : > What I am talking about is that explicit is better than implicit. Taking an > address of an object on a stack and passing it to a function that (possibly > can) delete your object is not explicit. That's why I advocate use of non-constant references ins

Re: [Development] unique_ptr and Qt, Take 2

>> Can you explain what you mean with “understands the parent/child-ownership >> model”? >> >> Are you suggesting a unique_ptr-like template class that doesn’t destroy the >> object in its destructor if that object still has a parent? > > It could be something like that. One option could be to b

Re: [Development] unique_ptr and Qt, Take 2

On 7 May 2019, at 15:00, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> wrote: On 6 May 2019, at 22:20, Lars Knoll mailto:lars.kn...@qt.io>> wrote: On 6 May 2019, at 20:23, André Pönitz mailto:apoen...@t-online.de>> wrote: On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote: On 6

Re: [Development] unique_ptr and Qt, Take 2

On 6 May 2019, at 22:20, Lars Knoll mailto:lars.kn...@qt.io>> wrote: On 6 May 2019, at 20:23, André Pönitz mailto:apoen...@t-online.de>> wrote: On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote: On 6 May 2019, at 09:30, Christian Kandeler mailto:christian.kande...@qt.io>> wrote: On Sat

Re: [Development] unique_ptr and Qt, Take 2

On 6 May 2019, at 20:23, André Pönitz mailto:apoen...@t-online.de>> wrote: On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote: On 6 May 2019, at 09:30, Christian Kandeler mailto:christian.kande...@qt.io>> wrote: On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen mailto:k...@carew

Re: [Development] unique_ptr and Qt, Take 2

On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote: > > On 6 May 2019, at 09:30, Christian Kandeler > > wrote: > > > > On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen > > wrote: > > > >> On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: > >>> On Friday, 3 May 2019 13

Re: [Development] unique_ptr and Qt, Take 2

Well, it should be possible, to support parents, created on the stack. We already have the code to do it. The code is private, unfortunately, but it doesn't matter. In the following file: qtbase/src/corelib/tools/qsharedpointer_impl.h We have the following constructor, used by QPointer: templa

Re: [Development] unique_ptr and Qt, Take 2

On 6 May 2019, at 10:27, Konstantin Shegunov mailto:kshegu...@gmail.com>> wrote: On Mon, May 6, 2019 at 10:42 AM Lars Knoll mailto:lars.kn...@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 cas

Re: [Development] unique_ptr and Qt, Take 2

On Mon, May 6, 2019 at 10:42 AM Lars Knoll 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

Re: [Development] unique_ptr and Qt, Take 2

> On 6 May 2019, at 09:30, Christian Kandeler wrote: > > On Sat, 04 May 2019 09:06:39 +0200 > Allan Sandfeld Jensen wrote: > >> On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: >>> On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: Which should be considered bad practice

Re: [Development] unique_ptr and Qt, Take 2

True, but it’s ownership is never transferred, so it’s out of the scope of discussion - user is free to use any c++ idiom he likes. I would like to discuss how to transfer ownership in modern Qt. > 6 мая 2019 г., в 9:30, Christian Kandeler > написал(а): > > On Sat, 04 May 2019 09:06:39 +0200 >

Re: [Development] unique_ptr and Qt, Take 2

On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen wrote: > On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: > > On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: > > > Which should be considered bad practice and banned on an API level > > > > No way. > > > > Are you g

Re: [Development] unique_ptr and Qt, Take 2

That’s exactly the problem we’re discussing here. Consider this example (was writing without a compiler, might be typos) class MyWidget : public QWidget { QWidget container; // note, doesn’t require explicit parent, layout handles that QLabel label; public: Widget(QWidget *parent) : Q

Re: [Development] unique_ptr and Qt, Take 2

On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: > On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: > > Which should be considered bad practice and banned on an API level > > No way. > > Are you going to forbid creation of QFile on the stack? Perhaps QFile shouldn't be the s

Re: [Development] unique_ptr and Qt, Take 2

Иван Комиссаров: IMHO, it should be a Qt6 feature. It’s awesome. However, I liked the idea (is it deprecated or what?) of a template method template std::observer_ptr qMakeChild(gsll::not_null> parent, Args… args) {     return parent->adoptChild(std::make_unique(args)); } For some classes

Re: [Development] unique_ptr and Qt, Take 2

what about the other corner case: ` ~Some() { const auto children = someChildren(); for (auto child : children) { if (!child->isDepleted()) { // 'detach' and let it die alone, some later... child->setParent(nullptr); QObject::connect(child, &Chil

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 16:14:09 PDT Иван Комиссаров wrote: > What I am talking about is that explicit is better than implicit. Taking an > address of an object on a stack and passing it to a function that (possibly > can) delete your object is not explicit. Wrapping that operation in a > constructio

Re: [Development] unique_ptr and Qt, Take 2

Ahhh, it so hard to explain things. Of course I am not suggesting to forbid creation of a QObject on a stack - it doesn’t make any sense to do that. What I am talking about is that explicit is better than implicit. Taking an address of an object on a stack and passing it to a function that (pos

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: > Which should be considered bad practice and banned on an API level No way. Are you going to forbid creation of QFile on the stack? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Product

Re: [Development] unique_ptr and Qt, Take 2

Il 04/05/19 00:33, Иван Комиссаров ha scritto: Back to the topic - in case we really want to support the "stack case", I’d say shared_ptr is the only option (in combination with enable_shared_from_this which is already a kinda part of QObject, as mentioned above) QObject ownership isn't share

Re: [Development] unique_ptr and Qt, Take 2

It seems I am having problems expressing my thoughts, people don’t understand what I am trying to say=( What I've meant is to have one allocation instead of two, yes, exactly. Back to the topic - in case we really want to support the "stack case", I’d say shared_ptr is the only option (in combi

Re: [Development] unique_ptr and Qt, Take 2

Il 03/05/19 23:03, Иван Комиссаров ha scritto: I’d say it’s an implementation detail - it *is* possible to implement the creation of QObjects more efficient than it is done now without «forcing» user to use objects on stack to avoid allocations. Unless you also sacrifice binary compatibility

Re: [Development] unique_ptr and Qt, Take 2

On Fri, May 3, 2019 at 11:02 PM Иван Комиссаров wrote: > Which should be considered bad practice and banned on an API level > On Fri, May 3, 2019 at 11:30 PM Иван Комиссаров wrote: > By forcing usage of smart pointers, of course. > That's a joke, right? Smart pointers aren't pointers, they ar

Re: [Development] unique_ptr and Qt, Take 2

Or maybe you can’t I didn’t think about the fact that public ctor allocates d_ptr itself… Need to think a bit more=( > 3 мая 2019 г., в 23:03, Иван Комиссаров написал(а): > > You can use the same technique in qMakeChild as in std::make_shared - to > allocate MyObjectPrivate and space for the d

Re: [Development] unique_ptr and Qt, Take 2

You can use the same technique in qMakeChild as in std::make_shared - to allocate MyObjectPrivate and space for the d_ptr in one go. Probably will require some additional macroses, though, to hide the implementation (sizeof(MyObjectPrivate)) in the cpp file. I’d say it’s an implementation detai

Re: [Development] unique_ptr and Qt, Take 2

03.05.2019, 23:31, "Иван Комиссаров" : > By forcing usage of smart pointers, of course. > The moment you start writing > > QWidget w1; > QWidget w2; > w1.setParent(QObjectSmartPointer(&w2)); > > It’s time to stop and think if you’re doing the right thing=) It is possible > to pass an object on a

Re: [Development] unique_ptr and Qt, Take 2

By forcing usage of smart pointers, of course. The moment you start writing QWidget w1; QWidget w2; w1.setParent(QObjectSmartPointer(&w2)); It’s time to stop and think if you’re doing the right thing=) It is possible to pass an object on a stack to a unique_ptr/shared_ptr ctor, but that’s the p

Re: [Development] unique_ptr and Qt, Take 2

Il 03/05/19 22:00, Иван Комиссаров ha scritto: Which should be considered bad practice and banned on an API level QWidget w2 QWidget w1; w1.setParent(&w2); QWidget w1; QWidget w2 w1.setParent(&w2); Banned at an API level -- how, exactly? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.c

Re: [Development] unique_ptr and Qt, Take 2

Which should be considered bad practice and banned on an API level QWidget w2 QWidget w1; w1.setParent(&w2); QWidget w1; QWidget w2 w1.setParent(&w2); Which one will crash?=) > 3 мая 2019 г., в 21:40, Thiago Macieira > написал(а): > > On Friday, 3 May 2019 12:32:01 PDT Allan Sandfeld Jensen

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 12:32:01 PDT Allan Sandfeld Jensen wrote: > Alternatively QObjects should be referenced counted, one reference could be > from a parent, but you could also strong reference with an explicit shared > pointer. The problem with that is that you can create QObjects on the stack a

Re: [Development] unique_ptr and Qt, Take 2

On Freitag, 3. Mai 2019 20:24:07 CEST Thiago Macieira wrote: > On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote: > > std::unique_ptr rightButton = > > std::make_unique("RIGHT"); > > layout->addWidget(std::move(rightButton)); > > The problem in this particular example is that once you've added

Re: [Development] unique_ptr and Qt, Take 2

That’s exactly why observer_ptr should not* be implemented as alias to a raw pointer; the main difference is that constructor from T* is explicit and there’s no implicit cast from observer_ptr to unique_ptr, so your example will not compile =) * well, the clang implementation I used forbids imp

Re: [Development] unique_ptr and Qt, Take 2

Just wandering, what `QObject:: children ()` shall return? ;p Konstantin пт, 3 мая 2019 г., 22:09 Konstantin Ritt : > Ivan, > > note that observer_ptr is mostly like > > templateusing observer_ptr = T*; > > > so what about > > > layout2->addWidget(layout->addWidget(make_unique("right")))->setFl

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote: > Anyhow, I too feel that we may need a dedicated smart pointer class for > this, to catch all the corner cases and allow the existing flow of > > 1) create something > 2) (re)parent it > 3) keep using that something via a

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 11:41:16 PDT Иван Комиссаров wrote: > auto button = layout->addWidget(make_unique(«RIGHT»)); > button->setFlat(true); The problem with code that has pre- and post-addition setup is that now you have two objects in the stack, which complicates your stack frame. The compilers

Re: [Development] unique_ptr and Qt, Take 2

Ivan, note that observer_ptr is mostly like templateusing observer_ptr = T*; so what about layout2->addWidget(layout->addWidget(make_unique("right")))->setFlat(true); ? Regards, Konstantin пт, 3 мая 2019 г., 21:41 Иван Комиссаров : > Thiago, can you please elaborate how you see this? >

Re: [Development] unique_ptr and Qt, Take 2

Hi, Il 03/05/19 19:22, Daniel Teske ha scritto: The first half of the program would thus look like: QWidget widget; QHBoxLayout *layout = widget.makeChild(); QPushButton *leftButton = widget.makeChild("LEFT"); layout->addWidget(leftButton); std::unique_ptr rightButton = std::make_unique("RIG

Re: [Development] unique_ptr and Qt, Take 2

Thiago, can you please elaborate how you see this? For a simple TreeItem a pair of std::unique_ptr/std::observer_ptr should be enough (with a bunch of convenience methods to insert children): struct TreeItem { observer_ptr parent; vector> children; }; Yes, the code becomes a bit verbose,

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote: > std::unique_ptr rightButton = > std::make_unique("RIGHT"); > layout->addWidget(std::move(rightButton)); The problem in this particular example is that once you've added the widget, the rightButton smart pointer no longer has a pointer. You

Re: [Development] unique_ptr and Qt, Take 2

On 03.05.19 11:24, Thiago Macieira wrote: On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote: std::unique_ptr rightButton = std::make_unique("RIGHT"); layout->addWidget(std::move(rightButton)); The problem in this particular example is that once you've added the widget, the rightButton smar

Re: [Development] unique_ptr and Qt, Take 2

+1 from my side. Explicit ownership declaration is the king. always - all other solutions are paid with sweat and blood. but mainly with blood... ;) Zoltan On Friday, May 3, 2019, Daniel Teske wrote: > Hi, > > a year back I wrote a patch that added unique_ptr apis to most of > qtbase. I still

Re: [Development] unique_ptr and Qt, Take 2

On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote: > std::unique_ptr rightButton = > std::make_unique("RIGHT"); > layout->addWidget(std::move(rightButton)); The problem in this particular example is that once you've added the widget, the rightButton smart pointer no longer has a pointer. You

Re: [Development] unique_ptr and Qt, Take 2

IMHO, it should be a Qt6 feature. It’s awesome. However, I liked the idea (is it deprecated or what?) of a template method template std::observer_ptr qMakeChild(gsll::not_null> parent, Args… args) { return parent->adoptChild(std::make_unique(args)); } With that method, you don’t need to imp

[Development] unique_ptr and Qt, Take 2

Hi, a year back I wrote a patch that added unique_ptr apis to most of qtbase. I still think that would be a good addition to Qt, and thus I've updated the patch with the feedback gained at the Contributor Summit last year and taking into account that with Qt6, binary compatibility is not requ

Re: [Development] unique_ptr and Qt

Thanks for doing this. Here is what i suggest to make the change less intrusive: For the constructors themself in every classes.   // Removed the '=nullptr' default parent, and added QT_UNSAFE_API   QT_UNSAFE_API explicit QLineEdit(QWidget *parent);   QT_UNSAFE_API explicit QLineEdit(const QSt

Re: [Development] unique_ptr and Qt

It would be nice if makeChild returned a some kind of «stupid» smart pointer (gsl::not_null maybe?) to indicate that object is not owned by holder (compare with raw pointer where the ownership is not known without reading doc): template QNonOwningPointer QObject::makeChild(Args&&... args); Ano

Re: [Development] unique_ptr and Qt

On 2018-06-05 14:40, Daniel Teske wrote: Hi, I've done some research into how supporting unique_ptr in Qt might look like. I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. Qt: h

Re: [Development] unique_ptr and Qt

On 5 June 2018 at 15:40, Daniel Teske wrote: > Hi, > > I've done some research into how supporting unique_ptr in Qt might look > like. > > I have a patch which adds apis using unique_ptr for ownership transfer to > almost all of QtBase and a patch for Qt Creator to show how using those apis > look

[Development] unique_ptr and Qt

Hi, I've done some research into how supporting unique_ptr in Qt might look like. I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. Qt: https://codereview.qt-project.org/231543