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
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
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
> 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+
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
Sorry, that was a typo, I should have written “resumability” , i.e.
pause/resume.
Can you also elaborate what do you mean by «reusability»? Ability to do
something like future.restart(); ?
1 февр. 2020 г., в 14:44, Sona Kurazyan
mailto:sona.kuraz...@qt.io>> написал(а):
In my understanding a
Ah, thanks.
Now I see why I am confused - in my understanding Task is something more
similar to std::function in terms that it it something that can be stored and
executed (somehow) later.
E.g. instead of doing something like
auto future = QtConcurrent::run(foo, value1, value2);
We do
auto task
Den lör 1 feb. 2020 kl 14:48 skrev Sona Kurazyan :
>
>
>
> > -Original Message-
> > From: Elvis Stansvik
> > Sent: Friday, January 31, 2020 7:20 PM
> > To: Sona Kurazyan
> > Cc: development@qt-project.org
> > Subject: Re: [Development] Make a decision for asynchronous APIs
> >
> > >
> > >
> -Original Message-
> From: Elvis Stansvik
> Sent: Friday, January 31, 2020 7:20 PM
> To: Sona Kurazyan
> Cc: development@qt-project.org
> Subject: Re: [Development] Make a decision for asynchronous APIs
>
> >
> > Additionally, there are some discussions about QFuture being a mix
> be
In my understanding a future represents a single result of a computation which
will be available sometime in future, it doesn’t assume reusability, progress
reporting, etc. If you take a look to other implementations of a future (like
boost::future, folly::future or std::experimental::future), n
So what you are suggesting, is basically the current QFuture (combined with
QFutureWtacher), but with "trimmed" runtime controls?
And if we do that, we also need to have QTask for the cases where the runtime
controls are needed (for example QtConcurrent, qtcreator).
Best regards,
Sona
> -O
Can you please elaborate the difference?
> 31 янв. 2020 г., в 17:24, Sona Kurazyan написал(а):
>
> Additionally, there are some discussions about QFuture being a mix between a
> “Task” and a “Future”. One of the options of improving this situation is to
> make a QTask (or QJob) out of the cur
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
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
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 «
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
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
On 31/01/20 23:04, Ville Voutilainen wrote:
> On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan
>>
>> I still have trouble understanding why std::unique_ptr is called like
>> this, whereas I could immediately understand what QScopedPointer does
>> even before reading its documentation.
>
> What would
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 move triggers a move of the payload of a scoped pointer to
another scop
On Samstag, 1. Februar 2020 00:31:17 CET Giuseppe D'Angelo wrote:
> On 31/01/2020 23:47, Allan Sandfeld Jensen wrote:
> >> The question stays: how do we call a unique_ptr equivalent?
> >
> > QScopedPointer? ;)
>
> That name was precisely the reason why the idea of adding movability was
> shot dow
20 matches
Mail list logo
