Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> > BTW, are you also planning to drop support for using PCH with GCC-like
> > compilers when building Qt? It's a thing that is trivial to do with make
> > or
> > qmake, but turns into rocket science with cmake.
> 
> PCH becomes "not our problem" if we switch to CMake. Please talk to CMake
> devs to make the feature possible.

PCH becomes *our problem* if we switch to CMake, same for iOS support!

Cheers,
BogDan.


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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> BTW, are you also planning to drop support for using PCH with GCC-like
> compilers when building Qt? It's a thing that is trivial to do with make or
> qmake, but turns into rocket science with cmake.

PCH becomes "not our problem" if we switch to CMake. Please talk to CMake devs 
to make the feature possible.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Thursday, 30 May 2019 15:37:32 PDT Konstantin Tokarev wrote:
> > I understand, but aside from qmake, I don't know of any build system that
> > allows for building both host and target in the same build. That means
> > whatever we use in Qt 6, we'll a separate build for host tools when cross-
> > compiling.
> 
> That's not exactly correct, as any build system which supports custom build
> rules (or "custom compilers" in qmake parlance) can implement such
> bootstrap without much pain. Most of build systems around, starting from
> good old make, support custom build rules [1]. Unfortunately, cmake is less
> expressive than make, as it supports [2] only custom targets ()

"without much pain" is incorrect. The whole point of having a buildsystem that 
is more complex than Make is to figure out where the compiler is, how to run 
it, how to create libraries and executables, at a minimum. Custom rules 
wouldn't benefit from that detection, which means we'd need to duplicate all 
of it in order to do everything in a single build.

Therefore, "with considerable pain".

> Fortunately, cmake has ExternalProject feature which can be used to work
> around this limitation. Cross build can build moc as a separate cmake
> project with host toolchain, and use it.

Which is what I said. A separate build step that bootstraps the tools.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Konstantin Tokarev]

31.05.2019, 00:57, "Thiago Macieira" :
> On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
>>  > 3) all tools in cross builds link to a host QtCore that must be
>>  > preinstalled Preferably, reuse the tools from that host build instead of
>>  > building again
>>  The latter item implies that there should be some compatibility gurantees
>>  allowing to use tools from Qt 6.x when building Qt 6.y, otherwise it will
>>  be really inconvenient
>
> I understand, but aside from qmake, I don't know of any build system that
> allows for building both host and target in the same build. That means
> whatever we use in Qt 6, we'll a separate build for host tools when cross-
> compiling.
>
> I don't see a problem in requiring the same version in the host and the target
> being built. But if this is not possible, then we'll need to have an extra
> step when preparing for cross-builds that bootstraps the host tools.

BTW, are you also planning to drop support for using PCH with GCC-like compilers
when building Qt? It's a thing that is trivial to do with make or qmake, but 
turns into
rocket science with cmake.

-- 
Regards,
Konstantin

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Konstantin Tokarev]

31.05.2019, 00:57, "Thiago Macieira" :
> On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
>>  > 3) all tools in cross builds link to a host QtCore that must be
>>  > preinstalled Preferably, reuse the tools from that host build instead of
>>  > building again
>>  The latter item implies that there should be some compatibility gurantees
>>  allowing to use tools from Qt 6.x when building Qt 6.y, otherwise it will
>>  be really inconvenient
>
> I understand, but aside from qmake, I don't know of any build system that
> allows for building both host and target in the same build. That means
> whatever we use in Qt 6, we'll a separate build for host tools when cross-
> compiling.

That's not exactly correct, as any build system which supports custom build 
rules
(or "custom compilers" in qmake parlance) can implement such bootstrap without
much pain. Most of build systems around, starting from good old make, support
custom build rules [1]. Unfortunately, cmake is less expressive than make, as it
supports [2] only custom targets ()

Fortunately, cmake has ExternalProject feature which can be used to work around
this limitation. Cross build can build moc as a separate cmake project with host
toolchain, and use it.

[1] IIRC Premake 5.x featured explicit support for using different toolchains 
for different
target in the same project

[2] Besides a few built-in "first class" languages, implemented in c++ core

[3] Yet I've seen people using cycles + add_custom_target() to compile source 
code
with a compiler built in the same cmake project

>
> I don't see a problem in requiring the same version in the host and the target
> being built. But if this is not possible, then we'll need to have an extra
> step when preparing for cross-builds that bootstraps the host tools.

ExternalProject to the rescue.

-- 
Regards,
Konstantin

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Thursday, 30 May 2019 14:34:52 PDT Konstantin Tokarev wrote:
> > 3) all tools in cross builds link to a host QtCore that must be
> > preinstalled Preferably, reuse the tools from that host build instead of
> > building again
> The latter item implies that there should be some compatibility gurantees
> allowing to use tools from Qt 6.x when building Qt 6.y, otherwise it will
> be really inconvenient

I understand, but aside from qmake, I don't know of any build system that 
allows for building both host and target in the same build. That means 
whatever we use in Qt 6, we'll a separate build for host tools when cross-
compiling.

I don't see a problem in requiring the same version in the host and the target 
being built. But if this is not possible, then we'll need to have an extra 
step when preparing for cross-builds that bootstraps the host tools.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Konstantin Tokarev]

31.05.2019, 00:19, "Thiago Macieira" :
> On Thursday, 30 May 2019 11:43:54 PDT Konstantin Tokarev wrote:
>>  Does it mean that moc will be reimplemented to avoid using Qt classes?
>
> No, but moc should be the only bootstrapped tool. My point is that we should
> do away with the bootstrap library.
>
> All other tools should like to QtCore. That means:
>
> 1) rcc should not be used in QtCore (easy to fix, can do in Qt 5 even)
>
> 2) all other tools in non-cross builds link to QtCore, as they do now
>
> 3) all tools in cross builds link to a host QtCore that must be preinstalled
> Preferably, reuse the tools from that host build instead of building again

The latter item implies that there should be some compatibility gurantees 
allowing
to use tools from Qt 6.x when building Qt 6.y, otherwise it will be really 
inconvenient

-- 
Regards,
Konstantin

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Thursday, 30 May 2019 11:43:54 PDT Konstantin Tokarev wrote:
> Does it mean that moc will be reimplemented to avoid using Qt classes?

No, but moc should be the only bootstrapped tool. My point is that we should 
do away with the bootstrap library.

All other tools should like to QtCore. That means:

1) rcc should not be used in QtCore (easy to fix, can do in Qt 5 even)

2) all other tools in non-cross builds link to QtCore, as they do now

3) all tools in cross builds link to a host QtCore that must be preinstalled
Preferably, reuse the tools from that host build instead of building again

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Simon Hausmann]

Yes, verdigris is awesome. Olivier rocks:)

I’m uncertain that it will be proposed as replacement for Qt 6 though.

I think it makes total sense side by side to the moc, in any case.

Simon

On 30. May 2019, at 21:00, NIkolai Marchenko 
mailto:enmarantis...@gmail.com>> wrote:

> So far nobody has stepped up to attempt to replace the mo
https://github.com/woboq/verdigris   not quite true

On Thu, May 30, 2019 at 9:59 PM Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:
So far nobody has stepped up to attempt to replace the moc, so I doubt that it 
will be replaced in Qt 6.

Simon

> On 30. May 2019, at 20:46, Konstantin Tokarev 
> mailto:annu...@yandex.ru>> wrote:
>
>
>
> 30.05.2019, 21:18, "Thiago Macieira" 
> mailto:thiago.macie...@intel.com>>:
>> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
>>> regarding to that in Qt 6.
>>
>> Bootstrap needs to go away in Qt 6.
>
> Does it mean that moc will be reimplemented to avoid using Qt classes?
>
> --
> Regards,
> Konstantin
>
> ___
> 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[NIkolai Marchenko]

> So far nobody has stepped up to attempt to replace the mo
https://github.com/woboq/verdigris   not quite true

On Thu, May 30, 2019 at 9:59 PM Simon Hausmann  wrote:

> So far nobody has stepped up to attempt to replace the moc, so I doubt
> that it will be replaced in Qt 6.
>
> Simon
>
> > On 30. May 2019, at 20:46, Konstantin Tokarev  wrote:
> >
> >
> >
> > 30.05.2019, 21:18, "Thiago Macieira" :
> >> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> >> wrote:
> >>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
> >>> regarding to that in Qt 6.
> >>
> >> Bootstrap needs to go away in Qt 6.
> >
> > Does it mean that moc will be reimplemented to avoid using Qt classes?
> >
> > --
> > Regards,
> > Konstantin
> >
> > ___
> > 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
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Giuseppe D'Angelo via Development]

Hi,

On 30/05/2019 20:20, Thiago Macieira wrote:

I like that idea. Maintains our API and semantics while removing our
implementation.

We may not even need CoW for those. Something to be benchmarked to see how
well we do. If we skip the CoW, we gain a bit in performance by removing a
level of indirection to the data.


Part of the reasoning was that QHash/QMap still jump through memory, so 
the extra indirection to keep CoW wouldn't drastically worsen things.


I would be against dropping CoW. It's been part of Qt's contract since 
forever and removing it has too far-reaching consequences.




== qHash() -> std::hash ==

Suggested by Lars in
https://codereview.qt-project.org/c/qt/qtbase/+/261819. To be precise,
he's suggesting to specialise std::hash and have qHash() call std::hash.

qHash() choices should be in tandem with QHash choices. If we make QHash wrap
std::unordered_map, then qHash gets deprecated. If QHash's implementation
stays, then so does qHash.


qHash can get deprecated, but I again would be against a source break. 
We'd need to find some template magic such that qHash is used, if 
present; otherwise std::hash is used.


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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Simon Hausmann]

So far nobody has stepped up to attempt to replace the moc, so I doubt that it 
will be replaced in Qt 6.

Simon

> On 30. May 2019, at 20:46, Konstantin Tokarev  wrote:
> 
> 
> 
> 30.05.2019, 21:18, "Thiago Macieira" :
>> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
>>> regarding to that in Qt 6.
>> 
>> Bootstrap needs to go away in Qt 6.
> 
> Does it mean that moc will be reimplemented to avoid using Qt classes?
> 
> -- 
> Regards,
> Konstantin
> 
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Simon Hausmann]

Hi,

If the Qt project decides to go with cmake, then I think that while bootstrap 
will remain for the moc and rcc, I think that we may be able to remove qregexp 
(Or QRegularExpression) from it. I doubt that either of them need it.

The cmake port fwiw is progressing very well and I hope that we will soon be 
able to make a proposal for the Qt project.

Simon

> On 30. May 2019, at 20:19, Thiago Macieira  wrote:
> 
> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development 
> wrote:
>> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
>> regarding to that in Qt 6.
> 
> Bootstrap needs to go away in Qt 6.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Konstantin Tokarev]

30.05.2019, 21:18, "Thiago Macieira" :
> On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development
> wrote:
>>  2) should QRegExp stay in bootstrap? I have no idea of what's happening
>>  regarding to that in Qt 6.
>
> Bootstrap needs to go away in Qt 6.

Does it mean that moc will be reimplemented to avoid using Qt classes?

-- 
Regards,
Konstantin

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 08:13:51 PDT Olivier Goffart wrote:
> I think we could get rid of QThread and get along with std::thread and
> std::thread::id
> We would have to keep a std::unordered_map,
> but that might be a bit difficult. (What happens if we do
> QObject::moveToThread(std::thread::id), and thread was already finished.
> We can mandate that an the thread has a Qt eventloop, so we can use TLS
> destructor to clean the map. But if we still access the thread handle after
> the thread terminate, we have a problem)

NAK on using a global. This should be in a TLS object.

I wish we could use thread_local on non-POD objects. But we'd need to drop 
MinGW compatibility if we did that. Can we?

> > === QMutex / QReadWriteLock -> std::*mutex* ===
> 
> The implementation of QMutex, and especially QReadWrtieLock is much more
> efficient that one of most standard library.
> 
> See https://woboq.com/blog/qreadwritelock-gets-faster-in-qt57.html
> 
> QMutex::lock  and QMutex::unlock  should be made inline, and then there
> should be less problems with TSAN (I assume the problem is that TSAN does
> not "see" the atomic operation when a Qt user uses QMutex and Qt itself was
> not compiled with TSAN,  and this is what you refer as work without hacks)

Agreed. The reason we kept them out-of-line was for the ability to use 
Transactional Memory when it became widely available. But after 5 years after 
the Haswell architecture came out, it's still not widely available -- it's 
only present in Intel processors with vPro, which are usually servers or high-
end desktops.

That said, we should have an out-of-line fallback for all cases, so TSAN and 
DRD work.

The other problem is:

> > === QWaitCondition -> std::condition_variable(_any) ===
> 
> Yes.

Can't change QWaitCondition without changing QMutex. It's all or nothing.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 10:29:37 PDT Vitaly Fanaskov wrote:
> 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
> guarantee this, this, and that under some circumstances”.

It's not rhetorical.

But it's interesting to note that since MSVC 2015, MS has kept its ABI for the 
C++ symbols and their standard library.

But having different #defines has caused ABI problems of our own. So it's 
unlikely we'll be able to retain ABI with MSVC across different compiler 
versions.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 08:17:15 PDT 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 types in the API now, even when not inline.

That's not correct. Keeping from the ODR violation is exactly why libc++ uses 
std::__1 namespace for its types. This allows for perfectly and strictly 
correct separation between a Qt internal use of std::vector and the user's use 
of std::__1::vector.

*Some* symbols aren't namespaced, like std::exception and std::type_info. But 
that's still not an ODR violation because the two implementations are strictly 
compatible: the layout is the same. That's true too for the the classes in the 
abi namespace, like abi::__si_class_type_info. There's a requirement on how 
the two libraries are built, but if it's wrong, it's just a distribution 
issue.

> Someone correct me if I'm wrong.

Done.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 08:22:28 PDT Allan Sandfeld Jensen wrote:
> 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, something that the STL doesn't, yet, have.

What's an OA hash container?

> > I don't think this is realistically possible. What I would suggest, to
> > bring the maintenance burden down to a minimum, and increase our
> > compatibility with stdlib to a maximum, is have QHash/QMap to be a CoW
> > wrapper for std::(unordered_)map . The inner data structure should be
> > exposed to the user, allowing for deep integration between stdlib and Qt.
> 
> I like that idea. Maintains our API and semantics while removing our
> implementation.

We may not even need CoW for those. Something to be benchmarked to see how 
well we do. If we skip the CoW, we gain a bit in performance by removing a 
level of indirection to the data.

Our discussion in QtCS a year or two ago was that we would keep these classes 
as wrappers around the std ones. Which brings me to:

> == qHash() -> std::hash ==
> 
> Suggested by Lars in
> https://codereview.qt-project.org/c/qt/qtbase/+/261819. To be precise,
> he's suggesting to specialise std::hash and have qHash() call std::hash.

qHash() choices should be in tandem with QHash choices. If we make QHash wrap 
std::unordered_map, then qHash gets deprecated. If QHash's implementation 
stays, then so does qHash.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 06:33:23 PDT Giuseppe D'Angelo via Development 
wrote:
> 2) should QRegExp stay in bootstrap? I have no idea of what's happening
> regarding to that in Qt 6.

Bootstrap needs to go away in Qt 6.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 05:22:45 PDT Jean-Michaël Celerier wrote:
> 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/

We want to, but it remains to be seen at time of actual work to see if it's a 
reasonable requirement.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] QList for Qt 6

[Thiago Macieira]

On Wednesday, 29 May 2019 02:26:57 PDT Lars Knoll wrote:
> > 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 begin pointer and size members move from
> > the  d pointer to the actual object. The slightly longer story is that
> > it's implemented using QArrayDataPointer and the supposedly
> > exception-safe, tag- dispatched operations in QArrayDataOps that João
> > wrote 7-8 years ago.
> 
> How important is exception safety? I’m rather unsure whether that’s
> required.

It's not. The point is that it's implemented. And the tag dispatching is 
actually an improvement over our current code, since it produces much more 
optimised code for the particulars of each T.

> > I also introduced a QGenericArray class that QVector derives from and
> > QList  could have, but doesn't look like it will be necessary for Qt 6.
> 
> 
> Weren’t you also thinking about using the same data structure for QByteArray
> and QString?

QArrayDataPointer yes. QGenericArray really is QVector, except for the methods 
that return QVector references.

But I never got either QByteArray or QString to use QADP. That's the point 
where I ran out of time 7 years ago.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Иван Комиссаров]

Until QList will be finally renamed=)

> 30 мая 2019 г., в 17:34, Giuseppe D'Angelo via Development 
>  написал(а):
> 
> Hi,
> 
> On 30/05/2019 10:23, Alberto Mardegan wrote:
>> I bet it's unused because everyone is using QList. But once we deprecate
>> QList, people will start asking for a CoW version of std::list.
> 
> QList has nothing to do with std::list!
> 
> (Except a very similar name.)
> 
> How many times does this need to be repeated?
> 
> Cheers,
> -- 
> 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
> 
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Giuseppe D'Angelo via Development]

Hi,

On 30/05/2019 10:23, Alberto Mardegan wrote:

I bet it's unused because everyone is using QList. But once we deprecate
QList, people will start asking for a CoW version of std::list.


QList has nothing to do with std::list!

(Except a very similar name.)

How many times does this need to be repeated?

Cheers,
--
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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Alberto Mardegan]

On 30/05/19 11:40, Mutz, Marc wrote:
> On 2019-05-30 10:23, Alberto Mardegan wrote:
>> It's not clear to me why splice() cannot be implemented: it would just
>> mean that the list data would detach as in all other non-const methods.
>> Or am I missing something?
> 
> You're passing two iterators. In order to implement slice(), you'd need
> to iterate over the list, counting the items, then detach, find the new
> two iterators, then do the slice(). That makes an O(M) operation into an
> O(2N) operation, M being the number of sliced entries (it was O(1) in
> C++98), N the size of the list.

But that happens only if you detach; otherwise the performance should be
comparable to std::list.  That detaching has a high cost is a known fact.

Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Bernhard Lindner]

> So, yes, this is borne out of frustration with the lack of maintenance 
> of QtCore plumbing. I don't see that changing and I acknowledge and 
> understand that the focus of development has shifted towards QML.

This exactly is the core problem. There are many things I could say about this. 
Allow me
one question instead:

Suppose you implement all planned actions for Qt6 (see your original e-mail). 
Are the
remaining components (those that are neither deprecated nor removed) of Qt6 well
maintained and are there enough staff available not only to maintain them 
indefinitely but
to actively develop them further?

-- 
Best Regards,
Bernhard Lindner

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Mutz, Marc via Development]

On 2019-05-30 10:23, Alberto Mardegan wrote:

It's not clear to me why splice() cannot be implemented: it would just
mean that the list data would detach as in all other non-const methods.
Or am I missing something?


You're passing two iterators. In order to implement slice(), you'd need 
to iterate over the list, counting the items, then detach, find the new 
two iterators, then do the slice(). That makes an O(M) operation into an 
O(2N) operation, M being the number of sliced entries (it was O(1) in 
C++98), N the size of the list.

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Alberto Mardegan]

On 29/05/19 13:53, Mutz, Marc via Development wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
> 
> These are basically Qt-internals, and should never have been public in
> the first place. It's _because_ they are public that we have two of
> them, and soon a third one (properly non-public):
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's
> message also explains what's wrong with the QSDP and QESDP.

No way :-)
I've never used QExplicitlySharedDataPointer myself, but
QSharedDataPointer is very useful; it should not be removed in Qt6.

And if it gets deprecated, an equally easy to use alternative should be
provided.

> == QScopedPointer -> std::unique_ptr ==
> 
> Suggested by Thiago on
> https://codereview.qt-project.org/c/qt/qtbase/+/261553
> 
> I agree. We now have std::unique_ptr, and it's movable. QScopedPointer
> had the problem that it didn't know what it wanted to be:
> boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not
> offer release(), a unique_ptr would need to provide move semantics.
> QScopedPointer has release(), but no moves (were proposed, but not
> accepted).

I never used release(), and I'm fine if std::unique_ptr is used as the
implementation. But the name QScopedPointer is so much better than
unique_ptr, that I wouldn't like to see it deprecated.

> == QLinkedList -> std::list
> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) ==
> 
> Of the Qt containers, this one is the most-unused (in Qt code), as well
> as the one that's furthest behind it's STL counter-part. Whenever I use
> std::list, I use it for splice(), a function that just cannot be added
> to a CoW container. Qt is already almost completely QLinkedList-free.
> Let's bury QLinkedList.

I bet it's unused because everyone is using QList. But once we deprecate
QList, people will start asking for a CoW version of std::list.

It's not clear to me why splice() cannot be implemented: it would just
mean that the list data would detach as in all other non-const methods.
Or am I missing something?


In general, I agree with the plan to make our classes more interoperable
with the STL, but I vote for keeping our own CoW classes and naming
conventions.


Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[d3fault]

On 5/29/19, Mutz, Marc via Development  wrote:
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place.
>

I disagree (unless there's some replacement you forgot to mention?).
Being able to create implicitly shared classes is extremely useful. I
consider implicit sharing and signals/slots, together, to to be one of
Qt's greatest strengths. They allow you to thread safely access/read a
"single" object across multiple threads without even thinking about
threading primitives such as mutex/waitcondition. You can also thread
safely modify/write to that object, by copying/detach()'ing just
before write (CoW).

I think the reason QSharedDataPointer hasn't seen very much use in
user code is because it's so darn tedious and time consuming to setup.
There's a lot of boilerplate/repetitive code in the EmployeeData
example of QSharedDataPointer's doc. At least that's why I
rarely/never use it in my own code. But there's a solution to that,
outlined here: https://bugreports.qt.io/browse/QTBUG-68589 (the
"Sample.isd"/json design in the comments of that bug report would be
very easy to implement).


> == QLinkedList -> std::list
> == QQueue / QStack -> std::queue, std::stack ==
> == QSet / QHash -> std::unordered_set/map ==
> == QMap -> std::map ==
>

Disagree. The software design process differs too greatly when dealing
with CoW vs. non-CoW containers. Assuming you could do s/QMap/std::map
(etc for all the containers) and have it compile without changing
anything else, there are just fundamental differences in the way
you're expected to use the containers. With Qt's CoW containers you
refer to a container by value, even from multiple threads
*simultaneously*, and it never performs a deep copy unless you try to
modify the container. ex:

Thread #0:
emit fooSignal(someQMap);

Thread #1:
void someFooSlot(someQMap)
{
m_MyCopy = someQMap; //with a CoW container the atomic reference
count is just incremented by 1. with a non-CoW container a deep copy
is performed here
}

Tons of user code was designed relying on there being CoW containers,
so removing it would make memory consumption skyrocket (OOM likely). I
don't see this as a feasible change. Hypothetically, how would one
thread safely share a std container with another thread (via
signals/slots) without performing a deep copy? Pass a
reference/pointer to the container and pass mutex along with it? That
would require lots of code changes (mutex.lock everywhere) and would
be prone to use-after-free errors (Qt's CoW semantics do lifetime
management seamlessly).

I recommend doing what someone else suggested in this thread: keep the
Qt'ish API (enqueue/dequeue vs. push/pop etc) and use the std
containers for the underlying implementation (just wrapped in CoW).


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