Re: [Development] unique_ptr and Qt, Take 2

[Lars Knoll]

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...@carewolf.com>> 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 going to forbid creation of QFile on the stack?

Perhaps QFile shouldn't be the same kind of base object type as
QWidgets? Or not use the same smart pointer.

Though even making QWidgets not allowed on the stack, while
sensible, would break a many of our tests, where we "abuse" that it
is technically possible in simple cases.

Doesn't almost every project create its main widget on the stack?

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.

I wonder whether there's a solution in the following direction:

Have something like the following for each QObject derived class Foo
(for which it makes sense. E.g. perhaps all widgets, but not QFile):

namespace Qt {

class Foo
{
public:
  Foo() : p(new QFoo), owning(true) {}
   // more ctors forwarding to QFoo ctor

  ~Foo() { if (owning) delete p; }

   // make  movable but not copiable...

  // forward QFoo interface to p->

private:
  QPointer p;  // Maybe QFoo *p.
  bool owning;  // Perhaps somehow mangled into p
  ...
  // whatever else is needed. Shouldn't be much.
};

} // namespace Qt

Those things could be 'stack only', and be reasonably explicit
about ownership without being too much of a pain to use.

Example code could be sth like:

int main(...)
{
  // a will own its a.p, and will destroy it when w itself dies.
  Application a(...);

  // w will own its w.p, and will destroy it when w itself dies.
  MainWindow w;

  // addChild would forward to QFoo's constructor and set 'owning'
  // to false on the resulting Foo, i.e. l is now known to be owned
  //  by something else, and will not destroy l.p in its dtor
  // w takes ownership of l, e.g. using the classic QObject
  // parent/child mechanisme on w.p and l.p. Or something else.
  Label l = w.addChild("Something");

  l.setSomething(..,); // call l.p->setSomething(...)

  w.show();  // call w.p->show()

  return a.exec(); // call a.p->show()

  // l will be destroyed, but not l.p as l.owning == false
  // w will be destroyed including w.p, and trigger the
  //   destruction of QItems created/owned by it, e.g. l.p
  // a will be destroyed including a.p
}

The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.

Interesting idea. I sometimes thought that if we’d be creating Qt from scratch, 
one could make it all value based and have the objects on the heap hidden 
behind it. This would give something similar. As an added benefit, we could 
probably allocate the object and it’s private in one go without requiring the 
TLS hacks that https://codereview.qt-project.org/#/c/165445/ uses.

This could maybe bet combined with a custom template class handling our 
pointers (instead of unique_ptr) that understands the parent/child ownership 
model, plus typedefs for the different QObject based classes in the Qt 
namespace.

Cheers,
Lars


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit Upgrade

[Konstantin Tokarev]

Are we planning to use Polymer-based UI, as currently used by Chromium and 
Android,
or the "old" one (which is probably still a default)? I believe "old" one has a 
horrible UX,
while Polymer one is a bit nicer. Also, Polymer's patch viewer plays nicely 
with X selection
buffer, while "old" does not.

06.05.2019, 15:18, "Frederik Gladhorn" :
> Hello,
>
> We've been working on the Gerrit Upgrade for a while now and we are finally
> getting ready to deploy the new goodness.
>
> We have all patches in our fork (yes, sadly we continue diverging a bit from
> mainstream, adding our own state handling for the CI).
> The good news is that there are very few changes to Gerrit itself and most of
> the code is now in a self-contained plugin.
>
> We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, that's
> a Monday, we assume Gerrit will be down for the full day that day).
> The plan is to not actually take that long, but we want to make sure things
> actually work after the long wait and there are one or two things we cannot
> test very well without the right domain and everything in place.
> Things look good though and I'm fairly confident that we'll manage the upgrade
> in May.
>
> We will collect some documentation here, currently it's just a placeholder
> page, not yet worth visiting, unless you know the newer Gerrit and want to
> help out documenting what is new:
> https://wiki.qt.io/Gerrit_Upgrade_2019
>
> Cheers,
> Frederik
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit Upgrade

[Sergio Ahumada]

On 06.05.19 14:16, Frederik Gladhorn wrote:
> Hello,
> 
> We've been working on the Gerrit Upgrade for a while now and we are finally 
> getting ready to deploy the new goodness.
> 
> We have all patches in our fork (yes, sadly we continue diverging a bit from 
> mainstream, adding our own state handling for the CI).
> The good news is that there are very few changes to Gerrit itself and most of 
> the code is now in a self-contained plugin.
> 
> We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, that's 
> a Monday, we assume Gerrit will be down for the full day that day).
> The plan is to not actually take that long, but we want to make sure things 
> actually work after the long wait and there are one or two things we cannot 
> test very well without the right domain and everything in place.
> Things look good though and I'm fairly confident that we'll manage the 
> upgrade 
> in May.
> 
> We will collect some documentation here, currently it's just a placeholder 
> page, not yet worth visiting, unless you know the newer Gerrit and want to 
> help out documenting what is new:
> https://wiki.qt.io/Gerrit_Upgrade_2019
> 
> Cheers,
> Frederik

Did you already try migrating the repos from the old Gerrit to the new
one? Is that why it would take the whole day?

If so, did you have to migrate step by step 2.7->2.8->...->2.15->2.16 or
directly from 2.7->2.16?

-- 
Sergio Ahumada
sahum...@texla.cl

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[André Pönitz]

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: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 same kind of base object type as
> >> QWidgets? Or not use the same smart pointer.
> >> 
> >> Though even making QWidgets not allowed on the stack, while
> >> sensible, would break a many of our tests, where we "abuse" that it
> >> is technically possible in simple cases.
> > 
> > Doesn't almost every project create its main widget on the stack? 
> 
> 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.

I wonder whether there's a solution in the following direction:

Have something like the following for each QObject derived class Foo
(for which it makes sense. E.g. perhaps all widgets, but not QFile):

namespace Qt {

class Foo 
{
public:
   Foo() : p(new QFoo), owning(true) {} 
// more ctors forwarding to QFoo ctor

   ~Foo() { if (owning) delete p; }

// make  movable but not copiable...

   // forward QFoo interface to p->

private:
   QPointer p;  // Maybe QFoo *p.
   bool owning;  // Perhaps somehow mangled into p
   ...
   // whatever else is needed. Shouldn't be much.
};

} // namespace Qt

Those things could be 'stack only', and be reasonably explicit
about ownership without being too much of a pain to use.

Example code could be sth like:

int main(...)
{
   // a will own its a.p, and will destroy it when w itself dies.
   Application a(...);

   // w will own its w.p, and will destroy it when w itself dies.
   MainWindow w;

   // addChild would forward to QFoo's constructor and set 'owning'
   // to false on the resulting Foo, i.e. l is now known to be owned
   //  by something else, and will not destroy l.p in its dtor
   // w takes ownership of l, e.g. using the classic QObject
   // parent/child mechanisme on w.p and l.p. Or something else.
   Label l = w.addChild("Something"); 

   l.setSomething(..,); // call l.p->setSomething(...)

   w.show();  // call w.p->show()

   return a.exec(); // call a.p->show()

   // l will be destroyed, but not l.p as l.owning == false
   // w will be destroyed including w.p, and trigger the
   //   destruction of QItems created/owned by it, e.g. l.p 
   // a will be destroyed including a.p
}

The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Vitaly Fanaskov]

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:

template  inline QWeakPointer(X *ptr, bool) : d(ptr ? 
Data::getAndRef(ptr) : nullptr), value(ptr) { }

That's it. We can use it for both case. There are some changes in QObject 
interface:

QObject(QWeakPointer parent = {})

// Use casting operator instead?

QWeakPointer asWeakRef() { return {this, true}; } QWeakPointer asWeakRef() const { return {this, true}; } QWeakPointer 
parent;

And some usage examples:

 auto o1 = QSharedPointer(new QObject);

auto o2 = new QObject(o1);

// Or...



QObject o1;

QObject o2(o1.asWeakRef());

I compiled and tested after patching Qt, works fine. Of course, I didn't 
implement full functionality, just a shallow example. QWeakPointer also 
gracefully handles the case if a user tries to invoke something like 
toStrongRef() in the second example. Some reasonable warning will be put to the 
terminal and an empty QSharedPointer returned.

This also means that we will have to use our own smart pointers everywhere in 
the interface (for consistency). We will also have to change some things (e.g., 
make QScopePointer movable), but this is the matter of another discussion. 
Which is not bad, because it'll help to avoid some well-known problems of using 
std::* in library interfaces, along with memory allocation/cleaning issues. And 
again, this is much better than having raw pointers.

On 5/6/19 12:04 PM, Lars Knoll wrote:

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 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?

It’s somewhat of a philosophical discussion now, as we are where we are and 
users can and are creating QObject’s on the stack. I don’t think we can change 
that now (even for Qt 6), and restricting it would lead to rather ugly syntax 
in C++ (as the language doesn’t really help enforcing something like this). So 
that means we’ll have to continue to support it.

Cheers,
Lars




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit Upgrade

[Frederik Gladhorn]

Hello,

We've been working on the Gerrit Upgrade for a while now and we are finally 
getting ready to deploy the new goodness.

We have all patches in our fork (yes, sadly we continue diverging a bit from 
mainstream, adding our own state handling for the CI).
The good news is that there are very few changes to Gerrit itself and most of 
the code is now in a self-contained plugin.

We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, that's 
a Monday, we assume Gerrit will be down for the full day that day).
The plan is to not actually take that long, but we want to make sure things 
actually work after the long wait and there are one or two things we cannot 
test very well without the right domain and everything in place.
Things look good though and I'm fairly confident that we'll manage the upgrade 
in May.

We will collect some documentation here, currently it's just a placeholder 
page, not yet worth visiting, unless you know the newer Gerrit and want to 
help out documenting what is new:
https://wiki.qt.io/Gerrit_Upgrade_2019

Cheers,
Frederik



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A monologue about platforms in the Qt world

[Giuseppe D'Angelo via Development]

Hi Tony,

On 02/05/2019 13:48, Tony Sarajärvi wrote:




What's a  supported platform?
---
It means that The Qt Company gives you support if you stumble upon a problem with that distro 


I don't agree on "The Qt Company gives you support" part. That's part of 
whatever commercial support agreement one gets from TQC; the "supported 
platform" definition (if any) should apply to the Qt Project, not to TQC.



and the Qt release promised to work on that. 


This is more like it. This promise should come from the "supported 
platforms" documentation pages, e.g.



https://doc.qt.io/qt-5/supported-platforms.html



https://doc.qt.io/qt-5/linux.html


It's however totally unclear at this point what "supported platform" 
means for the Qt Project. I've got a personal interpretation of this, 
but I don't know if it's codified somewhere. (E.g.: I consider a FTBFS 
on a supported platform a P1 and a release blocker).


Maybe it needs to be made clear, in Qt's policies as well as the 
official docs?




But what’s unclear is what it actually means that Qt should work on that 
platform. Does it mean that the binaries we distribute should work on that? Or 
does it mean that Qt builds on it if you take the sources and compile them 
yourself?


True, it's somewaht confusing for the end user. But IMHO I would not mix 
the two. To me, supported means that you can build from sources and run 
Qt there.


In other words, to me, it does not mean that a platform is supported iff 
there is a binary build of Qt available for that platform. Or, it does 
not mean that a platform is supported iff such binary builds "work".




 This is one of the most asked questions we’ve had here. A good example 
is openSUSE 42.3 where examples don’t compile if you take our binary 
release and try to work with that. But if you would compile Qt on that 
distro, then it would work. (see 
https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the 
details). What do you think it means? Is one or the other answers wrong 
here?


As a consequence of my position above: to me it means that openSUSE *is* 
supported (it's Linux/X11), but not by the binary builds.




Lifespan of distros
---
This is something we should have thought more about, but didn't. Perhaps still 
don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 
6th Dec 2018. It has a promised lifespan to at least the end of 2021. With us 
actually going development and testing before the actual release, we need to 
have the environment which we work on working at least 6 months before we 
release. Now that RHEL 7.4 was such an environment which was available then. 
Already released July 2017 and having an EOL (end of life) August 2019. 
Perfect! But the problem is our Qt 5.12.2, .3, .4, .5 releases. Should we be 
doing releases with a distro that isn't even supported by RedHat themselves? 
And there's the big question #1!

Because of ignorance we didn't think about this when we documented things. We 
just blindly say that Qt 5.12 supports RHEL 7.4, because that's what we have in 
the CI! Yeah, but are we really supporting it in 2021, when RedHat themselves 
have pulled the plug on it over 2 years before that? Could we just update to 
the latest RHEL after all? Especially since we didn't use RHEL 7.4 to begin 
with, but our own distro as we modified the original RHEL?


That's another area where this is mixing two levels of "support". Qt 
5.12 will be supported (by the _Qt Project_) until 2021. At least to me, 
the support for the binary builds can change at any time during this 
time frame, as the two supports are not tied to each other.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A monologue about platforms in the Qt world

[Volker Hilsheimer]

See inline.


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Danila Malyutin 
mailto:danilamalju...@gmail.com>>
Sent: Friday, May 3, 2019 4:07 PM
To: development@qt-project.org
Subject: Re: [Development] A monologue about platforms in the Qt world

> When selecting this operating system which we created packages with, we tend 
> to select a reasonable new one, most preferably a stable one, with a good set 
> of old libraries so that the backwards compatibility is good. Take RHEL 7 for 
> example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 
> update which we began using. RHEL 7.4 is still compatible with 7.0, which 
> means that our binaries are created with a new distro that creates binaries 
> compatible with distros created in 2014. At least sort of.

I found that to not be the case. For example, I couldn't get Qt Creator 4.8.0 
(which was the first one using Qt 5.12) to run on RHEL/CentOS 7.3 due to 
LIBDBUS_1_3 errors. Could be the same issue as with OpenSUSE though.

чт, 2 мая 2019 г. в 14:50, Tony Sarajärvi 
mailto:tony.saraja...@qt.io>>:
Hi all!

I'd like to open up a discussion about the platforms we "support".  This is 
like listening to a broken record, but once again it’s about adding or removing 
platforms in the CI, what’s supported and what we do packages with. But, this 
time I'm going to approach you a bit differently. Instead of simple questions, 
I'm going to bombard you with boring details. You need to know what exactly it 
is we are asking you about after all ;)


What's a  supported platform?
---
It means that The Qt Company gives you support if you stumble upon a problem 
with that distro and the Qt release promised to work on that. But what’s 
unclear is what it actually means that Qt should work on that platform. Does it 
mean that the binaries we distribute should work on that? Or does it mean that 
Qt builds on it if you take the sources and compile them yourself? This is one 
of the most asked questions we’ve had here. A good example is openSUSE 42.3 
where examples don’t compile if you take our binary release and try to work 
with that. But if you would compile Qt on that distro, then it would work. (see 
https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the 
details). What do you think it means? Is one or the other answers wrong here?


What a platform in the CI?
---
Ok this one is pretty clear. A platform in the CI is a platform we see fit to 
be tested for a specific branch. The important thing here is to realize that 
this is not the same thing as us supporting something. For obvious reasons it 
would be great if everything we supported was tested here, but because of the 
vast amount of combinations, we can't do that. We simply try to cover the most 
common cases here. And that's always up for debate! If you see that something 
is worth testing in the CI, create a ticket about it and justify why your 
configuration should be in there. This doesn't just mean adding platforms or 
compilers. It also means configurations like -no-gui or building examples for 
Android or something.


There are two perspectives to this: the Qt Project perspective, the The Qt 
Company perspective. As the company, "support" is a service we sell. People can 
ask for help, and we need to document on which platforms we help them with 
problems. That includes development hosts, and deployment targets.

For the Qt Project, what matters is which platforms we want our code to compile 
on, and for which platforms we want to provide pre-built binaries.

Ideally these two lists are mostly the same, but it's conceptually quite ok for 
TQtC to provide some platform support as a support or consulting service that 
includes developing patches. Might not be the most scalable business model 
under the sun, but whatever.

I perhaps recall this wrongly, but I think that's what we used to call "Tier 1" 
vs "Tier 2" supported platforms.

Tier 1 platforms: we provide tested binaries, verified through CI and 
pre-release package testing. You can expect a top out-of-the-installer 
experience.
Tier 2: things are supposed to work, but they might not, and if they don't 
we'll help you with fixing it.

This split still makes sense to me. The Qt Project at large should primarily 
care about Tier 1, ie contributors write code with those in mind (while being 
aware that there are also Tier 2 platforms); if changes break a tier 2, then it 
becomes TQtC’s problem to fix.



What's a packaging configuration and why don't Linux binaries work as promised?
---
Some configurations in the CI are used to actually create the binaries which we 
deliver as Qt binaries via the installer. They can be recognized by the 
"Packaging" keyword in the following files:
https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt
https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt
For most platforms this makes a lot 

[Development] Qt CMake Workshop May 2019 Summary

[Alexandru Croitor]

Hi,

Last week a bunch of Qt and KDAB people met to work on the Qt CMake port.

You can read the discussion notes and the work done at 
https://wiki.qt.io/CMake_Port/Development_Notes

It looks like Milestone 1 https://bugreports.qt.io/browse/QTBUG-73925 is 
getting closer to seeing the light.

Cheers,
Alexandru.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Lars Knoll]

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 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?

It’s somewhat of a philosophical discussion now, as we are where we are and 
users can and are creating QObject’s on the stack. I don’t think we can change 
that now (even for Qt 6), and restricting it would lead to rather ugly syntax 
in C++ (as the language doesn’t really help enforcing something like this). So 
that means we’ll have to continue to support it.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Konstantin Shegunov]

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 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?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Lars Knoll]

> 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 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 same kind of base object type as QWidgets? Or 
>> not use the same smart pointer.
>> 
>> Though even making QWidgets not allowed on the stack, while sensible, would 
>> break a many of our tests, where we "abuse" that it is technically possible 
>> in 
>> simple cases.
> 
> Doesn't almost every project create its main widget on the stack? 

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.

Cheers,
Lars



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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
> 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 going to forbid creation of QFile on the stack?
>> 
>> Perhaps QFile shouldn't be the same kind of base object type as QWidgets? Or 
>> not use the same smart pointer.
>> 
>> Though even making QWidgets not allowed on the stack, while sensible, would 
>> break a many of our tests, where we "abuse" that it is technically possible 
>> in 
>> simple cases.
> 
> Doesn't almost every project create its main widget on the stack? 
> 
> 
> Christian
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Christian Kandeler]

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 going to forbid creation of QFile on the stack?
> 
> Perhaps QFile shouldn't be the same kind of base object type as QWidgets? Or 
> not use the same smart pointer.
> 
> Though even making QWidgets not allowed on the stack, while sensible, would 
> break a many of our tests, where we "abuse" that it is technically possible 
> in 
> simple cases.

Doesn't almost every project create its main widget on the stack? 


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development