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,
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
>
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
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
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
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
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
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
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
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
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());
>
> It’s time to stop and think if you’re doing the right thing=) It is possible
> to pass an object on a
By forcing usage of smart pointers, of course.
The moment you start writing
QWidget w1;
QWidget w2;
w1.setParent(QObjectSmartPointer());
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
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();
QWidget w1;
QWidget w2
w1.setParent();
Banned at an API level -- how, exactly?
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com |
Which should be considered bad practice and banned on an API level
QWidget w2
QWidget w1;
w1.setParent();
QWidget w1;
QWidget w2
w1.setParent();
Which one will crash?=)
> 3 мая 2019 г., в 21:40, Thiago Macieira
> написал(а):
>
> On Friday, 3 May 2019 12:32:01 PDT Allan Sandfeld Jensen
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
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
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
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
>
>
>
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
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
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?
>
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 =
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,
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.
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
+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
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
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
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
> 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
Hi all,
Initial changes files for Qt 5.13.0 are now done, see
https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.13.0%22,n,z
Please finalize those as soon as possible & make sure those will get approval
immediately when ready.
Br,
Jani
+1 from my side. Please deprecate sqlite2 for 5.14 if that hasn’t been done yet.
Cheers,
Lars
On 3 May 2019, at 11:11, Volker Hilsheimer
mailto:volker.hilshei...@qt.io>> wrote:
+1 to dropping both sqlite2 and QTDS
Volker
From: Development
+1 to dropping both sqlite2 and QTDS
Volker
From: Development on behalf of Andy Shaw
Sent: Friday, May 3, 2019 10:52 AM
To: Albert Astals Cid; development@qt-project.org
Subject: Re: [Development] Dropping sqlite2 plugin for Qt6/cmake port
I am all for it, we
I am all for it, we should also drop QTDS at the same time, that has been
obsoleted since 4.7 and it is high time for removal.
Andy
-Original Message-
From: Development on behalf of
"development@qt-project.org"
Reply-To: Albert Astals Cid
Date: Friday, 3 May 2019 at 10:46
To:
While trying to get more src/plugins/sqldrivers/ code built with CMake i
realized that there is no FindSQLite2.cmake in cmake and we would have to
create/maintain our own.
Then i realized that the latest release of sqlite2 was on 2005 and thought
maybe we can just drop it?
So I'm proposing to
35 matches
Mail list logo
