On 7 May 2019, at 15:00, Volker Hilsheimer <volker.hilshei...@qt.io<mailto:volker.hilshei...@qt.io>> wrote:
On 6 May 2019, at 22:20, Lars Knoll <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> wrote: On 6 May 2019, at 20:23, André Pönitz <apoen...@t-online.de<mailto:apoen...@t-online.de>> wrote: On Mon, May 06, 2019 at 07:41:05AM +0000, Lars Knoll wrote: On 6 May 2019, at 09:30, Christian Kandeler <christian.kande...@qt.io<mailto:christian.kande...@qt.io>> wrote: On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen <k...@carewolf.com<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): […] 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. 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 behave like a unique_ptr if the object doesn’t have a parent, and like a weak pointer otherwise. One would have to try it out though, to see whether that would give semantics that are intuitive and feel right to users. Cheers, Lars
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
