On 2019-05-29 20:21, Vitaly Fanaskov wrote:
After all, STL updates approximately once in three years. So, we can
easily follow all changes and update Qt API accordingly. It’s
probably worth reusing something (e.g. time suffixes from chrono), but
carefully.
Well, yes. If Qt _had_ a track-record
Well I checked it with MinGW. The result was not so good.
Thank you, I will try to run benchmark with latest MSVC.
Best regards,
Mikhail
On Wed, 29 May 2019 at 20:37, Philippe wrote:
> For Windows, I am sure QMutex wins (with Visual Studio 2017).
> Not only I got much better figures, but trac
For Windows, I am sure QMutex wins (with Visual Studio 2017).
Not only I got much better figures, but tracing the assembly code of QMutex vs
std::mutex shows you why QMutex is better. Easy to check.
In release mode of course.
Philippe
On Wed, 29 May 2019 20:12:05 +0200
Mikhail Svetkin wrote:
>
All these have the same issue: You are proposing to deprecate Qt types in
favor of STL types, which have a different naming convention (_ vs. camel
case) and often terse, harder to understand names (e.g., ptr vs. Pointer,
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support
CoW
> The implementation of QMutex, and especially QReadWrtieLock is much more
efficient that one of most standard library.
I have run some benchmarks recently and the result did not show the QMutex
was the best.
I published the results here:
1.
https://bugreports.qt.io/browse/QTBUG-71036?focu
Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place.
Why? They are essential to be able to implement one's own CoW types and thus
write idiomatic Qt code.
I use Q
Well, but what about MSVC, for example, or some other compilers/|platforms?
This is rhetorical question, of course. I just want to say, that we cannot
guarantee this sort of compatibility for all build configurations. Hence, this
is unreliable unless we have a sort of public contract like “we gu
Do you know is there is any official policy published? I’ve tried to look into
both internet and intranet, but found pretty much nothing.
I entirely agree with increase of using new language features and STL, but it
should be done wisely and under well-defined policy. If we don’t have one, we
n
>I think we could get rid of QThread and get along with std::thread and
>std::thread::id
QThread being a QObject, lot of user code depends on that. And that's
a good dependency IMHO. I don't see any interest of getting rid of
QThread, on the contrary.
Philippe
__
On 29.05.19 17:17, Mutz, Marc via Development wrote:
But of course, that's a fallacy, because as soon as Qt internally uses said
inline functions, every use of them by the user with a different STL is an ODR
violation and therefore UB. So, again AFAICT, the decision was that we can use
std type
On Mittwoch, 29. Mai 2019 15:33:23 CEST Giuseppe D'Angelo via Development
wrote:
> Il 29/05/19 12:53, Mutz, Marc via Development ha scritto:
> > == QSet / QHash -> std::unordered_set/map ==
> >
> > I'd really like to see these gone. Mainly to free up their names for OA
> > hash containers, someth
On 2019-05-29 16:06, Vitaly Fanaskov wrote:
=== QAtomic -> std::atomic ===
It already is just a thin wrapper around std::atomic, so there's not
much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If so,
On 29.05.19 12:53, Mutz, Marc via Development wrote:
== MT plumbing ==
Let's make use of the std facilities to enable checkers such as TSAN to work
without hacks. It's not Qt's business to reimplement threading primitives.
Normally, checkers such as TSAN work out of the box.
But they kind of
> === QAtomic -> std::atomic ===
>
> It already is just a thin wrapper around std::atomic, so there's not
> much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If so, how all related
mess is supposed to
Il 29/05/19 12:53, Mutz, Marc via Development ha scritto:
Hi,
Here's a list of stuff I consider has served it's purpose and is no
longer needed, with respective replacements:
= Priority 1 =
== QSharedDataPointer / QExplicitlySharedDataPointer ==
These are basically Qt-internals, and should ne
29.05.2019, 15:49, "drwho" :
> On 2019-05-29 6:53 a.m., Mutz, Marc via Development wrote:
>> == QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
>>
>> Once they are stripped of their magic QObject handling and QObject
>> handling returned to QPointer proper, they don't do much othe
> Do you actually think it's Qt's job to define how _you_ implement your
> classes?
Yes, in parts, because there are good Qt concepts to reuse and compose with.
> I'd suggest boost::intrusive_ptr. It has a whole ecossytem with
> intrusive containers attached to it, IIRC.
If you suggest using b
29.05.2019, 15:52, "Mutz, Marc via Development" :
> On 2019-05-29 13:52, Konstantin Tokarev wrote:
>> 29.05.2019, 13:56, "Mutz, Marc via Development"
>> :
>>> Hi,
>>>
>>> Here's a list of stuff I consider has served it's purpose and is no
>>> longer needed, with respective replacements:
>>>
On 2019-05-29 13:52, Konstantin Tokarev wrote:
29.05.2019, 13:56, "Mutz, Marc via Development"
:
Hi,
Here's a list of stuff I consider has served it's purpose and is no
longer needed, with respective replacements:
= Priority 1 =
== QSharedDataPointer / QExplicitlySharedDataPointer ==
It see
On 2019-05-29 6:53 a.m., Mutz, Marc via Development wrote:
== QSharedPointer / QWeakPointer -> std::shared_ptr/weak_ptr ==
Once they are stripped of their magic QObject handling and QObject
handling returned to QPointer proper, they don't do much other than
std::shared_ptr, except being less
Hi everyone!
We have finally released Qt 5.13.0 Beta4. Delta to Beta3 attached.
Please take a tour & make sure possible new release blockers are visible in
release blocker list (https://bugreports.qt.io/issues/?filter=20625).
All known blockers are fixed and so on we are targeting to get RC out
> We probably need to keep QRWL around a while longer, since C++ added
shared_mutex only in C++17.
Wasn't it said at the world summit that Qt 6 would base itself on c++17 ?
https://blog.qt.io/blog/2018/06/13/qt-contributors-summit-2018-wrap/
Best,
Jean-Michaël
On Wed, May 29, 2019 at 12:55 PM M
Ah, I thought you'd might win this one :)
On 2019-05-29 13:48, Philippe wrote:
[snip usual rambling]
=== QAtomic -> std::atomic ===
There would be subbtle traps for code conversion:
eg. std::atomic::load() uses std::memory_order_seq_cst
while QAtomic::load() uses relaxed ordering
That is not
29.05.2019, 13:56, "Mutz, Marc via Development" :
> Hi,
>
> Here's a list of stuff I consider has served it's purpose and is no
> longer needed, with respective replacements:
>
> = Priority 1 =
>
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
It seems like you've forgotten migration p
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
No.
Very useful to create COW classes. Why removing this capability for Qt
users, while this is a common and useful Qt idiom?
>> === QAtomic -> std::atomic ===
There would be subbtle traps for code conversion:
eg. std::atomic::load() uses
Hi,
Here's a list of stuff I consider has served it's purpose and is no
longer needed, with respective replacements:
= Priority 1 =
== QSharedDataPointer / QExplicitlySharedDataPointer ==
These are basically Qt-internals, and should never have been public in
the first place. It's _because_
> On 28 May 2019, at 17:17, Thiago Macieira wrote:
>
> On Monday, 27 May 2019 04:51:35 PDT Eike Ziller wrote:
>>> * QVector for Qt 6 will most likely be updated with the changes Thiago has
>>> waiting since quite some years
>> What is the summary for these?
>
> The long story short is that the
27 matches
Mail list logo
