Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread André Pönitz
On Thu, Feb 13, 2020 at 10:01:02AM +, Maurice Kalinowski wrote: > > From: Development On Behalf Of > > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan > > Sandfeld Jensen Cc: development@qt-project.org > > Subject: Re: [Development] The future of

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread André Pönitz
On Thu, Feb 13, 2020 at 09:42:23AM +, Karsten Heimrich wrote: > -Original Message- > >From: André Pönitz Sent: Mittwoch, 12. Februar > >2020 19:38 Uhr To: Vitaly Fanaskov Cc: > >Karsten Heimrich ; development@qt-project.org > >Subject: Re: [Development] T

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Vitaly Fanaskov
As far as I know, there are no tasks created so far. I agree that we need to create a separate task, but not until the final decision. As it was mentioned in this thread, moving Qt smart pointers to Qt5Compat module is not discussed so far. What to do with existing public API that uses smart Qt

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Giuseppe D'Angelo via Development
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto: I think that moving Qt smart pointers to Qt5Compat module creates almost no hassle. For Qt users it should be a one line in the terminal to replace includes in their code bases (probably also prepend a namespace to classes' names, but I'm not sure if

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Maurice Kalinowski
> From: Development On Behalf Of > André Pönitz > Sent: Wednesday, February 12, 2020 8:00 PM > To: Allan Sandfeld Jensen > Cc: development@qt-project.org > Subject: Re: [Development] The future of smart pointers in Qt API > > On Wed, Feb 12, 2020 at 05:08:33PM +0100, All

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Vitaly Fanaskov
I think that moving Qt smart pointers to Qt5Compat module creates almost no hassle. For Qt users it should be a one line in the terminal to replace includes in their code bases (probably also prepend a namespace to classes' names, but I'm not sure if there is a namespace). In general, I'd say t

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Karsten Heimrich
-Original Message- >From: André Pönitz >Sent: Mittwoch, 12. Februar 2020 19:38 Uhr >To: Vitaly Fanaskov >Cc: Karsten Heimrich ; development@qt-project.org >Subject: Re: [Development] The future of smart pointers in Qt API > >On Wed, Feb 12, 2020 at 11:13:17AM +

Re: [Development] The future of smart pointers in Qt API

2020-02-13 Thread Vitaly Fanaskov
Yes, I see your point. The thing is that we need to narrow this discussion down and make a decision. Creating something like a wiki page would take a long time, I'm afraid. I think that there is should be a balance between collecting all possible opinions and trying to understand what contribut

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread André Pönitz
> On Mon, Feb 03, 2020 at 11:53:57PM +, Scott Bloom wrote: > > From: Development [mailto:development-boun...@qt-project.org] On > > Behalf Of André Pönitz > > [...] > > An actual "need" for a unique pointer is typically a sign that > > things are created, passed around until they end up somwher

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread André Pönitz
On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen wrote: > > Allowing _both_ I have not seen actively endorsed by anyone, > > this only makes a messy incosnsistent API. > > I would allow both. It is the only way to remain source > compatible, while making it possible for those that w

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread André Pönitz
On Wed, Feb 12, 2020 at 11:13:17AM +, Vitaly Fanaskov wrote: > >> We should also move Qt smart pointers to Qt5Compat module. The > >> destiny of QPointer is not well defined so far. > > > > This was not part of the research and should probably discussed > > separately. > > I agree. But if we de

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Allan Sandfeld Jensen
On Tuesday, 11 February 2020 20:19:36 CET André Pönitz wrote: > On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote: > > I want to summarize intermediate results of the discussion and return it > > back to the track. > > > > > > Subject: using smart pointers in the API. > > Good idea.

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Alberto Mardegan
On 12/02/20 15:20, Vitaly Fanaskov wrote: >> AFAIK, we don't have a procedure to make project-level decisions by majority >> vote. > True. We're discussing now. The goal here is to take people opinions and > arguments into account before making a decision. The problem I see, is that in your summ

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Vitaly Fanaskov
> AFAIK, we don't have a procedure to make project-level decisions by majority > vote. True. We're discussing now. The goal here is to take people opinions and arguments into account before making a decision. We have intermediate results of the discussion now. Next step is collecting the rest o

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Konstantin Tokarev
12.02.2020, 12:36, "Vitaly Fanaskov" : >>  You seem to repeat your initial statements. > > Yes, because most of the participants of this discussion tend to agree, > as far as I can see. AFAIK, we don't have a procedure to make project-level decisions by majority vote. If we want to achieve any

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Vitaly Fanaskov
evelopment On Behalf Of Vitaly >> Fanaskov >> Sent: Dienstag, 11. Februar 2020 16:15 Uhr >> To: development @qt-project.org >> Subject: Re: [Development] The future of smart pointers in Qt API >> >> I want to summarize intermediate results of the discussion

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Karsten Heimrich
Many thanks Vitaly for taking the time and effort to get the discussion going. -Original Message- >From: Development On Behalf Of Vitaly >Fanaskov >Sent: Dienstag, 11. Februar 2020 16:15 Uhr >To: development @qt-project.org > Subject: Re: [Development] The future of smart

Re: [Development] The future of smart pointers in Qt API

2020-02-12 Thread Vitaly Fanaskov
> You seem to repeat your initial statements. Yes, because most of the participants of this discussion tend to agree, as far as I can see. On 2/11/20 8:19 PM, André Pönitz wrote: > On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote: >> I want to summarize intermediate results of the

Re: [Development] The future of smart pointers in Qt API

2020-02-11 Thread André Pönitz
On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote: > I want to summarize intermediate results of the discussion and return it > back to the track. > > > Subject: using smart pointers in the API. > Good idea. Better to use than not because of automatic lifetime > management, *shru

Re: [Development] The future of smart pointers in Qt API

2020-02-11 Thread Vitaly Fanaskov
I want to summarize intermediate results of the discussion and return it back to the track. Subject: using smart pointers in the API. Good idea. Better to use than not because of automatic lifetime management, explicit ownership semantics, and code base maintainability is simpler. However, it

Re: [Development] The future of smart pointers in Qt API

2020-02-07 Thread Matthew Woehlke
On 07/02/2020 03.14, Eike Ziller wrote: > QList is most definitely a typedef to QVector in Qt/dev: What happened to providing a container type with guaranteed indirect storage? There remains no such type in STL. Last I saw, I thought we were going to provide that... -- Matthew _

Re: [Development] The future of smart pointers in Qt API

2020-02-07 Thread Eike Ziller
QList is most definitely a typedef to QVector in Qt/dev: https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qcontainerfwd.h > On 6. Feb 2020, at 20:20, Иван Комиссаров wrote: > > Wait, what?? When did that decision was made? > > I am tired fixing performance bugs induced be the repla

Re: [Development] The future of smart pointers in Qt API

2020-02-06 Thread Иван Комиссаров
Wait, what?? When did that decision was made? I am tired fixing performance bugs induced be the replacement QList with QList>, can we please get rid of the QList class finally? > 6 февр. 2020 г., в 20:14, Matthew Woehlke > написал(а): > I thought we decided *not* to > do that!) > __

Re: [Development] The future of smart pointers in Qt API

2020-02-06 Thread Matthew Woehlke
On 03/02/2020 16.25, Giuseppe D'Angelo via Development wrote: > Other people are free disagree with this. (For instance, in Qt 6 the > decision (which I disagree with) was to introduce similar gratuitous and > very hidden source-incompatible changes, e.g. with QList and QHash both > breaking iterat

Re: [Development] The future of smart pointers in Qt API

2020-02-05 Thread Ulf Hermann
> A "Qt style" "RAII handle" is a QObject parent at creation time. > There is no double deletion in this context, *only* when you start > to sprinkle in other ownership models, i.e. deviate from "Qt style". No. There are many places in our API that expect or return plain QObject pointers and you

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Ville Voutilainen
On Wed, 5 Feb 2020 at 00:04, André Pönitz wrote: > > > > Managed by what? Also, it seems downright detrimental if understanding > > > > basic C++ > > > > concepts is useless with Qt. > > > > > > I don't think that's received as much of an insult as you meant it to be > > > by parts of your audien

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread André Pönitz
On Tue, Feb 04, 2020 at 10:10:08PM +0200, Ville Voutilainen wrote: > On Tue, 4 Feb 2020 at 21:31, André Pönitz wrote: > > Seriously, *double deletion*? In real, proper Qt-style code? > > Yes, seriously, because allocated objects are stored in RAII handles A "Qt style" "RAII handle" is a QObject

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread André Pönitz
On Tue, Feb 04, 2020 at 07:42:22AM +0100, Giuseppe D'Angelo wrote: > Il 03/02/20 23:55, André Pönitz ha scritto: > > On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote: > > > Il 03/02/20 20:38, André Pönitz ha scritto: > > > > Directly affected are for instance functions operating on

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Konstantin Shegunov
On Tue, Feb 4, 2020 at 8:55 PM Daniel Teske wrote: > A QObject with a parent on the stack/unique_ptr is double owned and thus a > problem. The severity of that problem is arguably worse with a unique_ptr. > Which is rather typical in well structured and valid threaded code, where the children are

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread André Pönitz
On Tue, Feb 04, 2020 at 06:49:50AM +0100, Giuseppe D'Angelo wrote: > Il 04/02/20 00:49, André Pönitz ha scritto: > > > I've asked "what's wrong with the C++ smart pointers" a dozen times and > > > never received a satisfactory answer. > > Did you? I am - to some degree truly - afraid I didn't notic

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Ville Voutilainen
On Tue, 4 Feb 2020 at 21:31, André Pönitz wrote: > Seriously, *double deletion*? In real, proper Qt-style code? Yes, seriously, because allocated objects are stored in RAII handles so as to avoid leaking them on break/return/throw (or heaven forbid, goto). Then you can pass the result of a .relea

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Daniel Teske
Am 04.02.2020 um 17:47 schrieb Volker Hilsheimer: On 4 Feb 2020, at 16:12, Ville Voutilainen wrote: On Tue, 4 Feb 2020 at 15:40, Volker Hilsheimer wrote: This works, but now you are encoding the visual hierarchy of the widgets in two places: when asking the presumed parent to create the wid

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread André Pönitz
On Tue, Feb 04, 2020 at 07:17:13PM +0200, Ville Voutilainen wrote: > On Tue, 4 Feb 2020 at 18:48, Volker Hilsheimer > wrote: > > >>> But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to > > >>> behave imho saner in that edge case and actually delete the widgets that > > >>> we

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread André Pönitz
On Tue, Feb 04, 2020 at 03:52:34PM +, Vitaly Fanaskov wrote: > > I also don't think that this is something we should worry about when > discussing adding smart pointers. I think I've still not understood what "adding smart pointers" means when you use the term. Right now my impression is th

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Daniel Teske
Am 04.02.2020 um 13:22 schrieb Konstantin Shegunov: On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov > wrote: I think, if we decide to re-implement parent-child model using smart pointers, we would not use unique pointers at all. Even in a methods like Q

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Daniel Teske
Am 04.02.2020 um 07:53 schrieb Shawn Rutledge: On 1 Feb 2020, at 19:20, Daniel Teske > wrote: Now to take your next example: setParent is not fine. setParent can be used in 4 different ways: child->setParent(child->parent()): Invariant holds child->setParent(newParen

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Ville Voutilainen
On Tue, 4 Feb 2020 at 18:48, Volker Hilsheimer wrote: > >>> But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to > >>> behave imho saner in that edge case and actually delete the widgets that > >>> were added but never parented. (And I should really implement that to > >>> s

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Volker Hilsheimer
> On 4 Feb 2020, at 16:12, Ville Voutilainen > wrote: > > On Tue, 4 Feb 2020 at 15:40, Volker Hilsheimer > wrote: This works, but now you are encoding the visual hierarchy of the widgets in two places: when asking the presumed parent to create the widgets; and when setting up

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Vitaly Fanaskov
> Annotations could be used on the header files, and qdoc > could be smart enough to present them in a clear way. It could be a solution. However, I don't think that this is possible to have annotations for all objects passed or returned by raw pointers. Another thing is that you usually need to

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Alberto Mardegan
On 04/02/20 16:55, Vitaly Fanaskov wrote: > But if you see API like this: > > std::unique_ptr someAPI(); > > You have much more information about managed object just by reading the > code. This is also much easier to understand what can or cannot be done > with the returned value in the example

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Ville Voutilainen
On Tue, 4 Feb 2020 at 15:40, Volker Hilsheimer wrote: > >> This works, but now you are encoding the visual hierarchy of the widgets > >> in two places: when asking the presumed parent to create the widgets; and > >> when setting up the layout, which might do things differently (esp once > >> yo

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Vitaly Fanaskov
> Not using smart pointers in our API (neither the Qt's or the std:: ones) > allows each developer to use his own preferred solution with a minimal > effort. People might want to use boost smart pointers, SaferCPlusCplus, > or even their own handcrafted smart pointer templates. I don't think > that

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Volker Hilsheimer
> On 3 Feb 2020, at 19:09, Daniel Teske wrote: > > >> Hi Daniel, >> >> I like many things in this proposal, especially the principles; thanks for >> that! >> >> Where I’m on the fence is the replacing of setParent with “adoptChild”. I >> think of “parent” as a property of an object, so setPa

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Vitaly Fanaskov
I think that this case might be handled by using a smart pointer with a custom empty deleter. In this case we have absolutely the same potential issues as with a raw pointer to a stack object. Strictly speaking, something like that requires a great care and I'd recommend avoiding such approach.

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Konstantin Shegunov
On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov wrote: > I think, if we decide to re-implement parent-child model using smart > pointers, we would not use unique pointers at all. Even in a methods > like QObject::makeChild (because ownership is already defined). Shared + > weak pointers make perf

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Alberto Mardegan
Going back to the original question again, as I'm not sure I agree with this claim: On 31/01/20 13:07, Vitaly Fanaskov wrote: > Smart pointers are for sure much better to use than raw pointers for > many reasons. They manage lifetime automatically, show ownership > semantic, and make code safer.

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Vitaly Fanaskov
I think, if we decide to re-implement parent-child model using smart pointers, we would not use unique pointers at all. Even in a methods like QObject::makeChild (because ownership is already defined). Shared + weak pointers make perfect sense here. The main reason is that many other objects mi

Re: [Development] The future of smart pointers in Qt API

2020-02-04 Thread Fawzi Mohamed
Hi Daniel, I agree with most of your choices, and yes there will be cases where a change in QT is required. What I did not fully understand is why you did not go the whole way and used unique_ptr also in QObject, as Vitaly suggested: your invariant is either owned by a unique_ptr or a QObject,

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Shawn Rutledge
> On 3 Feb 2020, at 17:59, Jason H wrote: > > Recently this has caused me much consternation. I think QtQuick everything > should have a parent, and a visual parent, though I appreciate how tedious > this would be. They should be the same except when they can't and having > separate propertie

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Shawn Rutledge
On 1 Feb 2020, at 19:20, Daniel Teske mailto:q...@squorn.de>> wrote: Now to take your next example: setParent is not fine. setParent can be used in 4 different ways: child->setParent(child->parent()): Invariant holds child->setParent(newParent): Invariant holds child->setParent(nullptr): Nope

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Giuseppe D'Angelo via Development
Il 03/02/20 23:55, André Pönitz ha scritto: On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote: Il 03/02/20 20:38, André Pönitz ha scritto: Directly affected are for instance functions operating on full containers in https://doc.qt.io/qt-5/qtalgorithms-obsolete.html Just t

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Giuseppe D'Angelo via Development
Il 04/02/20 00:49, André Pönitz ha scritto: I've asked "what's wrong with the C++ smart pointers" a dozen times and never received a satisfactory answer. Did you? I am - to some degree truly - afraid I didn't notice. [snip] I apologize, I should've asked more clearly: "what's wrong with the C+

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Scott Bloom
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of André Pönitz Sent: Monday, February 3, 2020 3:50 PM To: Giuseppe D'Angelo Cc: development@qt-project.org Subject: Re: [Development] The future of smart pointers in Qt API On Mon, Feb 03, 2020 at 10:25:40PM

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread André Pönitz
On Mon, Feb 03, 2020 at 10:25:40PM +0100, Giuseppe D'Angelo via Development wrote: > I've asked "what's wrong with the C++ smart pointers" a dozen times and > never received a satisfactory answer. Did you? I am - to some degree truly - afraid I didn't notice. Answer would have been easy: They so

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread André Pönitz
On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote: > Il 03/02/20 20:38, André Pönitz ha scritto: > > Directly affected are for instance functions operating on full containers in > > > >https://doc.qt.io/qt-5/qtalgorithms-obsolete.html > > Just to set the record straight, the m

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Matthew Woehlke
On 01/02/2020 07.31, Allan Sandfeld Jensen wrote: > It is still a terrible name. Unique pointer refers to something > std::unique_ptr can abstractly achieve, but not what it actually is. It refers to something that had *better* be achieved, or else you're using it wrong. The *ownership* is uniqu

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Giuseppe D'Angelo via Development
Il 03/02/20 17:56, Jason H ha scritto: As a result, the code of a Qt-using program should be readable by average developers not big into C++. But no one is imposing super-advanced C++ features on Qt users and Qt applications... Meanwhile, it also does not serve anyone to duplicate stl. I d

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Giuseppe D'Angelo via Development
Il 03/02/20 20:38, André Pönitz ha scritto: Directly affected are for instance functions operating on full containers in https://doc.qt.io/qt-5/qtalgorithms-obsolete.html Just to set the record straight, the main reason why qAlgorithm(begin, end) as well as qAlgorithm(container) have bee

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Alberto Mardegan
On 03/02/20 19:56, Jason H wrote: > [...] As a result, the code of a Qt-using program > should be readable by average developers not big into C++. [...] I agree with all what you said; I'm just quoting this sentence because it's easy to underestimate this. Ciao, Alberto -- http://www.mardy.i

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread André Pönitz
On Sun, Feb 02, 2020 at 11:32:02PM +0100, Giuseppe D'Angelo wrote: > On 02/02/2020 22:45, André Pönitz wrote: > > > This is a logical fallacy; "I don't need it, noone else does". > > But this is the argument the de-Qt-ers use when it comes to Qt convenience > > they don't need. > > Which Qt conven

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Bernhard Lindner
I agree completely with Jason. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Daniel Teske
Hi Daniel, I like many things in this proposal, especially the principles; thanks for that! Where I’m on the fence is the replacing of setParent with “adoptChild”. I think of “parent” as a property of an object, so setParent/parent accessors are the API that fits into my mental model. I have

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Jason H
ruary 03, 2020 at 10:33 AM > From: "Mitch Curtis" > To: "Vitaly Fanaskov" , "Konrad Rosenbaum" > , "development@qt-project.org" > Subject: Re: [Development] The future of smart pointers in Qt API > > > Vitaly Fanaskov > > &g

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Jason H
ing number of al the time) > Sent: Sunday, February 02, 2020 at 6:00 AM > From: "Daniel Teske" > To: development@qt-project.org > Subject: Re: [Development] The future of smart pointers in Qt API > > > > Pros I can see: > > 1) Qt style >

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Mitch Curtis
> Vitaly Fanaskov > > [...] In this case, I think we won't have this confusing definitions like > "visual > parent" and "just a parent" > (that we have in controls). Sorry, couldn't resist: visual parent vs QObject parent is a distinction that Qt Quick made, not Qt Quick Controls.

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Vitaly Fanaskov
Yes in a current architecture it could be complicated. But if case of layouts, ownership is transferred to a layout. Other items might keep a weak references to a widget. Removing a widget invalidates all weak references. But, again, this only an assumption how it could be implemented. I actual

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Vitaly Fanaskov
> An alias from what to what? I'm a bit lost now. Something like: "using QScopedPointer = const std::unique_ptr". If we want an exact match. I think that this is also possible to omit "const" (yes, I know that some people would disagree). > But the premise of the of the argument was: "give me at

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Giuseppe D'Angelo via Development
Il 03/02/20 14:59, Vitaly Fanaskov ha scritto: If we're going for this logical fallacy, then let's up the ante: a unique pointer is just a shared pointer without copy semantics. Why not using shared pointers everywhere? Well, I hope it was rhetorical question, please, let me know if not. Yes

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Konrad Rosenbaum
On 2020-02-03 15:04, Vitaly Fanaskov wrote: We don't need this method at all if everything is implemented with using smart pointers. What about the case when I want to delete a Widget from my window without closing the window? I often use deleteLater() because it is much easier than remember

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Volker Hilsheimer
> On 1 Feb 2020, at 19:20, Daniel Teske wrote: >> Parent-child relationship is not going to go away, it has purpose beyond >> object lifetime: the visual hierarchy is encoded in the parent/child >> relationship of widgets, for example. >> >> Making ownership of objects, and assumptions regardin

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Vitaly Fanaskov
We don't need this method at all if everything is implemented with using smart pointers. On 2/2/20 6:17 PM, Иван Комиссаров wrote: > Can we please return to the discussion about QObject parent/child with smart > pointers rather than discussing Qt/stl naming? > > No one answered my question about

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Vitaly Fanaskov
If we're going for this logical fallacy, then let's up the ante: a unique pointer is just a shared pointer without copy semantics. Why not using shared pointers everywhere? Well, I hope it was rhetorical question, please, let me know if not. The difference between shared pointer and unique point

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Ola Røer Thorsen
søn. 2. feb. 2020 kl. 00:15 skrev Giuseppe D'Angelo via Development < development@qt-project.org>: > If we're going for this logical fallacy, then let's up the ante: a > unique pointer is just a shared pointer without copy semantics. Why not > using shared pointers everywhere? > > I'm not sure if

Re: [Development] The future of smart pointers in Qt API

2020-02-03 Thread Fawzi Mohamed
Hi Daniel, Thanks for the nice work of looking to use unique_ptr, I like it, I think it makes ownership clearer. About having wrappers or not I am still on the fence, I think using stl when possible is a good idea, but I see the advantage of having consistent naming, so I am not sure about the b

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 22:45, André Pönitz wrote: This is a logical fallacy; "I don't need it, noone else does". But this is the argument the de-Qt-ers use when it comes to Qt convenience they don't need. Which Qt convenience in particular? I seem to be advocating against duplication "for the sake of

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Daniel Teske
Am 02.02.2020 um 18:17 schrieb Иван Комиссаров: Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread André Pönitz
On Sun, Feb 02, 2020 at 07:55:09PM +0100, Giuseppe D'Angelo via Development wrote: > On 02/02/2020 17:38, Alberto Mardegan wrote: > > On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: > > > Il 01/02/20 12:37, Alberto Mardegan ha scritto: > > > > Do we need to have such a counterpart? In

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 21:26, Alberto Mardegan wrote: This is a logical fallacy; "I don't need it, noone else does". Yes, but it's a logical fallacy you yourself made up Excuse me? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::uniq

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Alberto Mardegan
On 02/02/20 21:55, Giuseppe D'Angelo via Development wrote: > On 02/02/2020 17:38, Alberto Mardegan wrote: >> Believe it or not :-) I find std::shared_ptr easier to use when passing >> pointers to and from functions. And I never needed to put them into an >> array. > > This is a logical fallacy; "

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 19:19, Иван Комиссаров wrote: > > Can we please return to the discussion about QObject parent/child with smart > pointers rather than discussing Qt/stl naming? > > No one answered my question about QObject::deleteLater: > > > And what about the QObject::deleteLater() method?

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 17:34, Alberto Mardegan wrote: On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:44, Alberto Mardegan ha scritto: On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: About QUniquePointer: what's the point of reinventing std::unique_ptr under a dif

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 17:38, Alberto Mardegan wrote: On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: Il 01/02/20 12:37, Alberto Mardegan ha scritto: Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Giuseppe D'Angelo via Development
On 02/02/2020 18:17, Иван Комиссаров wrote: No one answered my question about QObject::deleteLater: And what about the QObject::deleteLater() method? Any ideas how this should look like with smart pointers? You can specify custom deleters for smart pointers. For QScopedPointer there's alrea

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Иван Комиссаров
Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: > And what about the QObject::deleteLater() method? Any ideas how this should > look like with smart pointers? __

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 18:40, Alberto Mardegan wrote: > The STL could still add a method made up of two words in the future, and > it's unlikely that they'll use camelCase (or that they'd accept a > camelCase variant). Unlikely to the point that it's safe to bet against it. ___

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Alberto Mardegan
On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:37, Alberto Mardegan ha scritto: >> Do we need to have such a counterpart? In my work experience, when I'm >> not allowed to use Qt and am restricted to the STL, all the times I had >> to use std::unique_ptr was to get the

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Alberto Mardegan
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:44, Alberto Mardegan ha scritto: >> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: >>> About QUniquePointer: what's the point of reinventing std::unique_ptr >>> under a different name? >> >> A Qt-ish API! > >

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Ville Voutilainen
On Sun, 2 Feb 2020 at 01:14, Giuseppe D'Angelo via Development wrote: > With this I can totally agree. As I said countless times, the only way > to influence such naming decisions is working _with_ upstream (by the > way, the meetings are pretty much public) and bringing your arguments on > naming

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Daniel Teske
Pros I can see: 1) Qt style STL has different naming convention that looks alien to Qt API. It leads to inconsistency. The "Qt projects not using the standard library" era is over and the sooner that is understood the better. That inconsistency is just something to get used too Qt does no

Re: [Development] The future of smart pointers in Qt API

2020-02-02 Thread Christian Ehrlicher
Am 02.02.2020 um 01:00 schrieb Иван Комиссаров: I would also like to add the argument about templates. Qt API is still incompatible with STL in some places, so one cannot write a template function that simply calls STL variant. For example: QString foo; if (std::empty(foo)) // oops, fails to comp

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Иван Комиссаров
I would also like to add the argument about templates. Qt API is still incompatible with STL in some places, so one cannot write a template function that simply calls STL variant. For example: QString foo; if (std::empty(foo)) // oops, fails to compile because QString misses the .empty() method

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Giuseppe D'Angelo via Development
Il 01/02/20 13:31, Allan Sandfeld Jensen ha scritto: On Samstag, 1. Februar 2020 10:15:02 CET you wrote: Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto: To me the name is still perfect. It makes perfect sense. Just because it is movable doesn't mean you move the object itself, a move moves

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Giuseppe D'Angelo via Development
Hi, Il 01/02/20 22:55, Vitaly Fanaskov ha scritto: The consensus was reached against such a decision. A scoped pointer should not be able to escape scope. Yes, in C++17 this is now not entirely true, but the name strongly implies it. Perhaps, it's a good time to reconsider it. Scoped

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Vitaly Fanaskov
> The consensus was reached against such a decision. A scoped pointer > should not be able to escape scope. Yes, in C++17 this is now not > entirely true, but the name strongly implies it. Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity in light of modern C+

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Daniel Teske
Parent-child relationship is not going to go away, it has purpose beyond object lifetime: the visual hierarchy is encoded in the parent/child relationship of widgets, for example. Making ownership of objects, and assumptions regarding their life-cycle, explicit in code is a good thing though

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Giuseppe D'Angelo via Development
Il 01/02/20 12:37, Alberto Mardegan ha scritto: Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::unique_ptr was to get the same behaviour as a QScopedPointer. So you never had to pass one t

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Allan Sandfeld Jensen
On Samstag, 1. Februar 2020 10:15:02 CET you wrote: > Il 01/02/20 09:27, Allan Sandfeld Jensen ha scritto: > > To me the name is still perfect. It makes perfect sense. Just because it > > is > > movable doesn't mean you move the object itself, a move moves the content > > of the object. So each mov

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Иван Комиссаров
Do I understand correctly that proposition of usage of the shared_ptr instead of unique_ptr is to have a drop-in replacement for a QPointer (weak_ptr)? Can we implement It somehow with the unique_ptr? And what about the QObject::deleteLater() method? I always found it pretty ugly (what if that «

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Giuseppe D'Angelo via Development
Il 01/02/20 12:44, Alberto Mardegan ha scritto: On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name? A Qt-ish API! Example? * Is it just going to be an alias, to be more Qtish? Then why QS

Re: [Development] The future of smart pointers in Qt API

2020-02-01 Thread Alberto Mardegan
On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: > About QUniquePointer: what's the point of reinventing std::unique_ptr > under a different name? A Qt-ish API! > * Is it just going to be an alias, to be more Qtish? Then why > QSharedPointer is NOT going to be an alias? > > * Is it no

  1   2   >