date:20190821



22.08.2019, 02:39, "Kevin Kofler" :
> André Pönitz wrote:
>>  Traditionally, "ease of use" and "consistent API" have been a core values
>>  of Qt, even consciously bought at the cost of some bytes and some cycles.
>>
>>  Of course, this has meant that in certain parts of certain types of
>>  applications Qt could not sensibly be used. Still, in most cases all, or
>>  almost all of the code could be "plain Qt", benefiting for creation and
>>  maintenance from those values. I do believe this was a sensible setup for
>>  Qt, and I do think there's room for a general purpose framework living
>>  that compromise also in today's world.
>>
>>  During the last years (ok, let's say, starting around \epsilon A.J. -
>>  "After Jasmin") this promise has been more or less silently broken, once
>>  by "leaf" modules deviating, partially intentionally, from previous naming
>>  conventions, then for real accidents that couldn't be corrected due to
>>  too-late discovery and compatibility promises, and finally by attempts to
>>  provide "high performance" alternatives in some places.
>>
>>  In the end we lost uniform, easy-to-use interfaces, and the performance
>>  gains are only present in very isolated areas of the offering with long
>>  stretches in-between, hidden by obscure and continuously changing do's and
>>  don'ts so that they are effectively not visible in real-world GUI-centric
>>  applications.
>
> The creeping STLization of Qt (deprecating some classes for STL
> alternatives, using STL classes in some APIs, etc.) is also part of this
> disturbing trend. It typically regresses both ease of use and API
> consistency in the name of the holy performance cow.

If you don't need performance, don't use C++. For example, consider Qt for 
Python.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Kevin Kofler

André Pönitz wrote:
> Traditionally, "ease of use" and "consistent API" have been a core values
> of Qt, even consciously bought at the cost of some bytes and some cycles.
> 
> Of course, this has meant that in certain parts of certain types of
> applications Qt could not sensibly be used. Still, in most cases all, or
> almost all of the code could be "plain Qt", benefiting for creation and
> maintenance from those values. I do believe this was a sensible setup for
> Qt, and I do think there's room for a general purpose framework living
> that compromise also in today's world.
> 
> During the last years (ok, let's say, starting around \epsilon A.J. -
> "After Jasmin") this promise has been more or less silently broken, once
> by "leaf" modules deviating, partially intentionally, from previous naming
> conventions, then for real accidents that couldn't be corrected due to
> too-late discovery and compatibility promises, and finally by attempts to
> provide "high performance" alternatives in some places.
> 
> In the end we lost uniform, easy-to-use interfaces, and the performance
> gains are only present in very isolated areas of the offering with long
> stretches in-between, hidden by obscure and continuously changing do's and
> don'ts so that they are effectively not visible in real-world GUI-centric
> applications.

The creeping STLization of Qt (deprecating some classes for STL 
alternatives, using STL classes in some APIs, etc.) is also part of this 
disturbing trend. It typically regresses both ease of use and API 
consistency in the name of the holy performance cow.

Kevin Kofler

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 15:00:14 PDT NIkolai Marchenko wrote:
> > Note: DO NOT use -static with MSVC 2017.
> 
> Can you provide the link to the bug in question? I've seen you mention it
> several times and I am curious.

https://bugreports.qt.io/browse/QTBUG-59570
https://bugreports.qt.io/browse/QTBUG-61074
https://bugreports.qt.io/browse/QTBUG-61752
https://bugreports.qt.io/browse/QTBUG-67969
https://bugreports.qt.io/browse/QTBUG-68029
https://bugreports.qt.io/browse/QTBUG-73217

https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html
https://connect.microsoft.com/VisualStudio/feedback/details/3136520
https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html
https://developercommunity.visualstudio.com/comments/237118/view.html

https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.7
 says it had fixed the bug, but didn't. As of 15.9 it was still there, so 
the fix is in the version after that: 16.0.

-- 
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread NIkolai Marchenko

>  Note: DO NOT use -static with MSVC 2017.
Can you provide the link to the bug in question? I've seen you mention it
several times and I am curious.

On Thu, Aug 22, 2019 at 12:58 AM Thiago Macieira 
wrote:

> On Wednesday, 21 August 2019 13:26:48 PDT Henry Skoglund wrote:
> > I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be
> > happily built using /MT then that would beat MinGW, since such an .exe
> > wouldn't then even require msvcrt.dll.
>
> It can be. That's what the -static-runtime option to configure does
> (additional to -static).
>
> Note: DO NOT use -static with MSVC 2017.
>
> --
> 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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 13:39:55 PDT Kai Pastor, DG0YT wrote:
> Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2.
> For building Windows applications, you use a MinGW subsystem, and there
> is no msys-2.0.dll.

That's just MinGW, albeit the build from MSYS2. If that's what was meant, I'm 
all for it. After the upgrade I've just run, I have GCC 9.2, which is great.

But I had understood the proposal as linking to MSYS2 libraries.

-- 
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 13:26:48 PDT Henry Skoglund wrote:
> I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be
> happily built using /MT then that would beat MinGW, since such an .exe
> wouldn't then even require msvcrt.dll.

It can be. That's what the -static-runtime option to configure does 
(additional to -static).

Note: DO NOT use -static with MSVC 2017.

-- 
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] HEADS-UP: QStringLiteral

2019-08-21 Thread André Pönitz

On Wed, Aug 21, 2019 at 10:01:29AM +, Tor Arne Vestbø wrote:
> > On 21 Aug 2019, at 11:50, Bogdan Vatra via Development
> >  wrote:
> > 
> > Am I the only one which finds situations silly ? Of course there are more 
> > examples
> > with the other String wrappers/functions in Qt, but I think is enough to 
> > show how
> > crazy is the situation.
> 
> You are not! 

Indeed.

> I completely agree, and I think it’s a detriment to Qt’s promise of easy to 
> use APIs
> that these optimised versions are not automagic and hidden behind the scenes, 
> or
> don’t have a clear cut story for when to explicitly use.

Same here.

Traditionally, "ease of use" and "consistent API" have been a core values of Qt,
even consciously bought at the cost of some bytes and some cycles.

Of course, this has meant that in certain parts of certain types of applications
Qt could not sensibly be used. Still, in most cases all, or almost all of the 
code
could be "plain Qt", benefiting for creation and maintenance from those values.
I do believe this was a sensible setup for Qt, and I do think there's room for
a general purpose framework living that compromise also in today's world.

During the last years (ok, let's say, starting around \epsilon A.J. - "After
Jasmin") this promise has been more or less silently broken, once by "leaf" 
modules
deviating, partially intentionally, from previous naming conventions, then for 
real
accidents that couldn't be corrected due to too-late discovery and compatibility
promises, and finally by attempts to provide "high performance" alternatives in
some places.

In the end we lost uniform, easy-to-use interfaces, and the performance gains 
are
only present in very isolated areas of the offering with long stretches 
in-between,
hidden by obscure and continuously changing do's and don'ts so that they are
effectively not visible in real-world GUI-centric applications.

With Qt 6 approaching, we could, at least in theory, revert steps on the 
"un-Qt-ish"
path, or opt for any of the alternatives ("modern C++ trumps all", "performance
trumps all", "random hogwash of whatever gets a +2 on Gerrit").

I surely have a preference here, but I'll be probably ok with anything that 
follows
*some* rules set, but I'd like to have a conscious decision on that.

If that does not happen, we will continue on the hogwash path.  For me that'd 
be the
least preferable option of all.

Andre'

PS:

> > test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1);
> > test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // 
> > wrong again
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
> > still wrong
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
> > victory
> 
> This should just be test[“key”] = “value”. How do we get there?

One option is to use QT_RESTRICTED_CAST_FROM_ASCII instead of 
QT_NO_CAST_FROM_ASCII
for your application.

Yes, that costs cycles. But one is still free to use The Right Decorations in 
the
handful places where one doesn't want to in an application.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Kyle Edwards

On Wed, 2019-08-21 at 17:25 -0400, Kyle Edwards wrote:
> If you don't own the copyright, and you can't get permission from the
> copyright holder, then my guess would be no, unless you can
> successfully argue that the MSVC runtime *is* a system library (even
> though it's not distributed with Windows.)

Looks like the FSF has weighed in on this exact topic:

https://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL

You can link a GPL program against the MSVC runtime and claim it as a
system library, but you cannot then distribute the MSVC runtime with
your application. The user would have to download the runtime
themselves... which defeats the entire purpose of this exercise.

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

Nice. Those .exe files would be closer to 30 MB than 20 MB, right? But 
nowadays that kind of sizes are quite common/normal and does not incur 
any noticeable delays when launching them.


Building static Qt apps this way for Windows I think will be more 
popular. I wish Qt would include a static building wizard, like showing 
say the most common static build flavors as check boxes, and perhaps a 
detailed view for cherrypicking exactly what modules you want.


Rgrds Henry

On 2019-08-21 23:10, Ola Røer Thorsen wrote:
ons. 21. aug. 2019 kl. 20:54 skrev Henry Skoglund >:



I've switched from VS to MinGW, the #1 reason: I can distribute an
.exe
file which is runnable directly on the user's desktop (no
installation).
This is *verboten* when using VS, you have to send along the
distribution dlls (ucrtbase.dll etc.) and install them.


Agreed. I cross-build completely statically linked Qt quick apps on 
Linux using mingw-w64 and share them (.exe only, no DLLs) to 
colleagues who only run windows. Very useful! So I would not vote for 
requiring MSYS2 or similar if it would mean the end of cross building 
Windows apps on Linux (if I've understood what MSYS2 is correctly).


I would not however mind upgrading the compiler/toolchain if my 
particular one was too old for some future Qt version.


Cheers,
Ola


___
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Kyle Edwards

On Wed, 2019-08-21 at 22:43 +0200, Kai Pastor, DG0YT wrote:
> Is it possible to distribute a GPL-3 licensed application this way? 
> After all, these DLLs are neither system libraries nor are they are 
> offered under compatible terms.

IANAL. If you own the copyright then you can of course license it under
GPL-3 with an exception to allow linking to the MSVC runtime.

If you don't own the copyright, and you can't get permission from the
copyright holder, then my guess would be no, unless you can
successfully argue that the MSVC runtime *is* a system library (even
though it's not distributed with Windows.)

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Ola Røer Thorsen

ons. 21. aug. 2019 kl. 20:54 skrev Henry Skoglund :

>
> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
> file which is runnable directly on the user's desktop (no installation).
> This is *verboten* when using VS, you have to send along the
> distribution dlls (ucrtbase.dll etc.) and install them.
>
>
Agreed. I cross-build completely statically linked Qt quick apps on Linux
using mingw-w64 and share them (.exe only, no DLLs) to colleagues who only
run windows. Very useful! So I would not vote for requiring MSYS2 or
similar if it would mean the end of cross building Windows apps on Linux
(if I've understood what MSYS2 is correctly).

I would not however mind upgrading the compiler/toolchain if my particular
one was too old for some future Qt version.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Giuseppe D'Angelo via Development


Il 21/08/19 18:46, Tor Arne Vestbø ha scritto:

You mean foo[QString(“bar”)] = QString(“baz”)?


No, I mean

QHash foo;
foo["bar"] = "baz";

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: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Kai Pastor, DG0YT


Am 21.08.19 um 21:36 schrieb Kyle Edwards:

On Wed, 2019-08-21 at 21:22 +0200, Elvis Stansvik wrote:

Why not just ship those DLLs? I wouldn't call that "verboten"
(forbidden), just a bit more to do for deployment.

It's not "verboten", but it's also not as straightforward as
redistributing free software like MinGW.

From https://docs.microsoft.com/en-us/visualstudio/productinfo/2015-red
istribution-vs :

"If you have a validly licensed copy of such software, you may copy and
distribute with your program the unmodified form of the files listed
below, subject to the License Terms for the software."

This sounds to me like you have to download a copy of Visual Studio
before redistributing the DLLs, and agree to all of the licensing
terms. (I highly doubt that this would/could actually be enforced in
any meaningful way, but for people who are picky about open source vs
proprietary licenses, this is still another unwanted hoop to jump
through.)


Is it possible to distribute a GPL-3 licensed application this way? 
After all, these DLLs are neither system libraries nor are they are 
offered under compatible terms.



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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Kai Pastor, DG0YT


Am 21.08.19 um 22:03 schrieb Thiago Macieira:

On Wednesday, 21 August 2019 12:54:11 PDT Thiago Macieira wrote:

MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
porting Unix software to Windows and I love that it gives me a bash and
pacman for when I need to develop on Windows. But it's emulation, like:
https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Packages (3) mintty-1~3.0.2-1  msys2-runtime-3.0.7-6  pacman-5.1.3-3
[...]
warning: terminate MSYS2 without returning to shell and check for updates
again
warning: for example close your terminal window instead of calling exit

This happens because msys-2.0.dll keeps a shared memory segment between all
instances MSYS2 applications, so they behave as if they were in a Unix system.

Note that this is the MSYS subsystem, not a MinGW subsystem of MSYS2. 
For building Windows applications, you use a MinGW subsystem, and there 
is no msys-2.0.dll.


https://github.com/msys2/msys2/wiki/MSYS2-introduction

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)


Hi, no I was only thinking of /MD all the time.

I thought Qt required /MD, but maybe I am an /MT ignoramus, if Qt can be 
happily built using /MT then that would beat MinGW, since such an .exe 
wouldn't then even require msvcrt.dll.



On 2019-08-21 21:59, Konstantin Tokarev wrote:


21.08.2019, 22:39, "Henry Skoglund" :

Yes, I also used app-local deployment, problem is that Microsoft has not
committed 100% to allow it (as far as I know), instead they have a
seesaw approach, saying "you can temporarily use app-local deployment but.."

Anyway, my ultimate goal is to create and distribute my Qt apps the same
way as Qt's installation program (you can tell I really admire that
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous
.exe file (which only needs msvcrt.dll). And that kind of linking,
Microsoft has never supported nor allowed it.

Does it mean that distribution of software built with /MT runtime is illegal?



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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 12:54:11 PDT Thiago Macieira wrote:
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and
> pacman for when I need to develop on Windows. But it's emulation, like:
> https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

$ pacman -Su
:: Starting core system upgrade...
warning: terminate other MSYS2 programs before proceeding
resolving dependencies...
looking for conflicting packages...

Packages (3) mintty-1~3.0.2-1  msys2-runtime-3.0.7-6  pacman-5.1.3-3
[...]
warning: terminate MSYS2 without returning to shell and check for updates 
again
warning: for example close your terminal window instead of calling exit

This happens because msys-2.0.dll keeps a shared memory segment between all 
instances MSYS2 applications, so they behave as if they were in a Unix system.

-- 
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)



21.08.2019, 22:39, "Henry Skoglund" :
> Yes, I also used app-local deployment, problem is that Microsoft has not
> committed 100% to allow it (as far as I know), instead they have a
> seesaw approach, saying "you can temporarily use app-local deployment but.."
>
> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.

Does it mean that distribution of software built with /MT runtime is illegal?

-- 
Regards,
Konstantin

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)



21.08.2019, 22:56, "Thiago Macieira" :
> On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development
> wrote:
>>  Instead, please consider switching to MSYS2 for Qt6
>
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and pacman
> for when I need to develop on Windows. But it's emulation, like:
> https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc
>
> Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is
> supposed to be *actual* Windows.

MSYS2 provides repositories with native toolchains (i.e., MinGW) and libraries 
as well.

-- 
Regards,
Konstantin

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Elvis Stansvik

Den ons 21 aug. 2019 kl 21:36 skrev Henry Skoglund :
>
> Yes, I also used app-local deployment, problem is that Microsoft has not
> committed 100% to allow it (as far as I know), instead they have a
> seesaw approach, saying "you can temporarily use app-local deployment but.."
>
> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.

Alright, yes, your argument (and Kyle's) make sense I guess. I was
mostly speaking from a practicality perspective (that deployment is
really not that awkward with the right tools).

I know that Microsoft once said it would no longer support app-local
deployment of the Universal CRT, but then changed their mind back in
2015 (see the bullet point 6 in the list at
https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/).

I don't know if they've changed their mind again, which I think would
be required to really call it a seesaw approach :)

But yea, I too prefer the simplicity of an MIT licensed compiler to
Microsofts agreement.

Elvis

>
>
> On 2019-08-21 21:22, Elvis Stansvik wrote:
> > Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
> >> Please, don't drop MinGW, it's in my meaning the best compiler on Windows.
> >>
> >> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
> >> file which is runnable directly on the user's desktop (no installation).
> >> This is *verboten* when using VS, you have to send along the
> >> distribution dlls (ucrtbase.dll etc.) and install them.
> > Why not just ship those DLLs? I wouldn't call that "verboten"
> > (forbidden), just a bit more to do for deployment.
> >
> > We do app-local deployment (putting the DLLs next to our application),
> > which is still supported, and makes it possible for us to deliver a
> > portable ZIP in addition to an installer. You don't have to go the
> > route of launching the redistributables installer.
> >
> > To make it less inconvenient we use CMake's
> > InstallRequiredSystemLibraries module along with setting
> > CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
> > also bundled.
> >
> > Elvis
> >
> >> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
> >> also switched from using Visual Studio to MinGW. I believe for the same
> >> reason as mine above, except MaintenanceTool.exe didn't include any VS
> >> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
> >> start, because no VS2015 runtime was installed.
> >>
> >> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
> >> present, and tbat .dll always gonna be there (just like the VB6 runtime
> >> etc.)
> >>
> >> This is one of the few places where Windows still shines: Qt's OOBE on
> >> Windows. On that platform, you don't need any chmod +x or waiting for a
> >> .dmg to unpack, just double-click on the .exe file.
> >>
> >> Rgrds Henry
> >>
> >>
> >>
> >> On 2019-08-21 20:35, Mathias Hasselmann wrote:
> >>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
>  PPS: can we drop MinGW support in Qt 6?
> >>> What alternative do you propse?
> >>> ___
> >>> 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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 12:29:29 PDT Massimo Callegari via Development 
wrote:
> Instead, please consider switching to MSYS2 for Qt6

MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for 
porting Unix software to Windows and I love that it gives me a bash and pacman 
for when I need to develop on Windows. But it's emulation, like:
https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc

Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is 
supposed to be *actual* Windows.

-- 
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

On Wednesday, 21 August 2019 11:35:37 PDT Mathias Hasselmann wrote:
> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
> > PPS: can we drop MinGW support in Qt 6?
> 
> What alternative do you propse?

Clang/MinGW. However, after a quick test, turns out that this code only 
compiles under Clang trunk. Not even Clang 8 can compile it:

struct S { S(); ~S(); };

void f()
{
thread_local S s;
}

https://mingw.godbolt.org/z/nzHBEH
error: cannot compile this non-trivial TLS destruction yet

The same code compiled with the GCC/MinGW 8.2 that I have on my openSUSE 
system. (I'd have tested GCC/MinGW on Windows, but the terminal and/or bash 
refuse to paste text) I don't know when GCC implemented the functionality.

So let me instead change my request:
Can we require GCC 8 for MinGW for Qt 5.15?

That way, we can ressurrect Q_THREAD_LOCAL and eventually replace with 
thread_local.

-- 
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Kyle Edwards

On Wed, 2019-08-21 at 21:22 +0200, Elvis Stansvik wrote:
> Why not just ship those DLLs? I wouldn't call that "verboten"
> (forbidden), just a bit more to do for deployment.

It's not "verboten", but it's also not as straightforward as
redistributing free software like MinGW.

From https://docs.microsoft.com/en-us/visualstudio/productinfo/2015-red
istribution-vs :

"If you have a validly licensed copy of such software, you may copy and
distribute with your program the unmodified form of the files listed
below, subject to the License Terms for the software."

This sounds to me like you have to download a copy of Visual Studio
before redistributing the DLLs, and agree to all of the licensing
terms. (I highly doubt that this would/could actually be enforced in
any meaningful way, but for people who are picky about open source vs
proprietary licenses, this is still another unwanted hoop to jump
through.)

On the other hand, the terms of MinGW are quite clear: it's an MIT-like 
license which allows you to redistribute with only minimal requirements
(retain the copyright notice) ( http://www.mingw.org/license ).

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

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

Yes, I also used app-local deployment, problem is that Microsoft has not 
committed 100% to allow it (as far as I know), instead they have a 
seesaw approach, saying "you can temporarily use app-local deployment but.."


Anyway, my ultimate goal is to create and distribute my Qt apps the same 
way as Qt's installation program (you can tell I really admire that 
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous 
.exe file (which only needs msvcrt.dll). And that kind of linking, 
Microsoft has never supported nor allowed it.



On 2019-08-21 21:22, Elvis Stansvik wrote:

Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :

Please, don't drop MinGW, it's in my meaning the best compiler on Windows.

I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
file which is runnable directly on the user's desktop (no installation).
This is *verboten* when using VS, you have to send along the
distribution dlls (ucrtbase.dll etc.) and install them.

Why not just ship those DLLs? I wouldn't call that "verboten"
(forbidden), just a bit more to do for deployment.

We do app-local deployment (putting the DLLs next to our application),
which is still supported, and makes it possible for us to deliver a
portable ZIP in addition to an installer. You don't have to go the
route of launching the redistributables installer.

To make it less inconvenient we use CMake's
InstallRequiredSystemLibraries module along with setting
CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
also bundled.

Elvis


Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
also switched from using Visual Studio to MinGW. I believe for the same
reason as mine above, except MaintenanceTool.exe didn't include any VS
.dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
start, because no VS2015 runtime was installed.

Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
present, and tbat .dll always gonna be there (just like the VB6 runtime
etc.)

This is one of the few places where Windows still shines: Qt's OOBE on
Windows. On that platform, you don't need any chmod +x or waiting for a
.dmg to unpack, just double-click on the .exe file.

Rgrds Henry



On 2019-08-21 20:35, Mathias Hasselmann wrote:

Am 21.08.2019 um 19:38 schrieb Thiago Macieira:

PPS: can we drop MinGW support in Qt 6?

What alternative do you propse?
___
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Massimo Callegari via Development

-1 IMHO too

Instead, please consider switching to MSYS2 for Qt6. It's much more structured 
than *bare* MinGW and it offers an increasing number of libraries out of the 
box.

I believe many developers would appreciate it, and I suspect it would help the 
Qt company too when packaging non-VS-Qt for Windows.

Also, MSYS2 is used by AppVeyor as CI system. I use it for my project. It's 
fantastic.

Please, I don't want to use Micro$oft stuff.

Massimo


 Il mercoledì 21 agosto 2019, 20:37:56 CEST, Mathias Hasselmann 
 ha scritto:

Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
> PPS: can we drop MinGW support in Qt 6?
What alternative do you propse?

___
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Elvis Stansvik

Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
>
> Please, don't drop MinGW, it's in my meaning the best compiler on Windows.
>
> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
> file which is runnable directly on the user's desktop (no installation).
> This is *verboten* when using VS, you have to send along the
> distribution dlls (ucrtbase.dll etc.) and install them.

Why not just ship those DLLs? I wouldn't call that "verboten"
(forbidden), just a bit more to do for deployment.

We do app-local deployment (putting the DLLs next to our application),
which is still supported, and makes it possible for us to deliver a
portable ZIP in addition to an installer. You don't have to go the
route of launching the redistributables installer.

To make it less inconvenient we use CMake's
InstallRequiredSystemLibraries module along with setting
CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
also bundled.

Elvis

>
> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
> also switched from using Visual Studio to MinGW. I believe for the same
> reason as mine above, except MaintenanceTool.exe didn't include any VS
> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
> start, because no VS2015 runtime was installed.
>
> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
> present, and tbat .dll always gonna be there (just like the VB6 runtime
> etc.)
>
> This is one of the few places where Windows still shines: Qt's OOBE on
> Windows. On that platform, you don't need any chmod +x or waiting for a
> .dmg to unpack, just double-click on the .exe file.
>
> Rgrds Henry
>
>
>
> On 2019-08-21 20:35, Mathias Hasselmann wrote:
> > Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
> >> PPS: can we drop MinGW support in Qt 6?
> > What alternative do you propse?
> > ___
> > 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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)


Please, don't drop MinGW, it's in my meaning the best compiler on Windows.

I've switched from VS to MinGW, the #1 reason: I can distribute an .exe 
file which is runnable directly on the user's desktop (no installation). 
This is *verboten* when using VS, you have to send along the 
distribution dlls (ucrtbase.dll etc.) and install them.


Also, big wheels like Qt's installer program (MaintenanceTool.exe) have 
also switched from using Visual Studio to MinGW. I believe for the same 
reason as mine above, except MaintenanceTool.exe didn't include any VS 
.dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to 
start, because no VS2015 runtime was installed.


Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be 
present, and tbat .dll always gonna be there (just like the VB6 runtime 
etc.)


This is one of the few places where Windows still shines: Qt's OOBE on 
Windows. On that platform, you don't need any chmod +x or waiting for a 
.dmg to unpack, just double-click on the .exe file.


Rgrds Henry



On 2019-08-21 20:35, Mathias Hasselmann wrote:

Am 21.08.2019 um 19:38 schrieb Thiago Macieira:

PPS: can we drop MinGW support in Qt 6?

What alternative do you propse?
___
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] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

2019-08-21 Thread Mathias Hasselmann


Am 21.08.2019 um 19:38 schrieb Thiago Macieira:

PPS: can we drop MinGW support in Qt 6?

What alternative do you propse?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 09:44:55 PDT Tor Arne Vestbø wrote:
> I have to double check the dyld sources, but in many cases the dlclose will
> be a no-op, and the image won’t actually unload. One of these conditions
> was (if I recall correctly) if the library had any thread local storage.

Oh, that's an interesting trick, yeah. Pretty sure all systems will have a 
similar issue, since C++11 thread_local requires that non-PODs be 
destructible, which means the system needs to know that the destructor is 
still present when the thread exits.

If they don't, then it's going to possibly crash the same way that 
QStringLiteral today does.

PS: this is also why we can't use thread_local in Qt 6 just yet. MinGW does 
not support those with non-trivial destructors.

PPS: can we drop MinGW support 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] HEADS-UP: QStringLiteral

2019-08-21 Thread bogdan--- via Development



În 21 august 2019 19:46:26 EEST, "Tor Arne Vestbø"  a 
scris:
>
>
>> On 21 Aug 2019, at 18:32, Giuseppe D'Angelo via Development
> wrote:
>> 
>> On 21/08/2019 18:21, Tor Arne Vestbø wrote:
>>> I would not want to have those “you’re using a fast, but not optimal
>version of the N string classes” warnings unless I was writing string
>heavy and performance sensitive code.
>> 
>> So just use QString :-)
>
>You mean foo[QString(“bar”)] = QString(“baz”)?
>
>That’s already two QStrings too much  
>


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

Re: [Development] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 18:32, Giuseppe D'Angelo via Development 
>  wrote:
> 
> On 21/08/2019 18:21, Tor Arne Vestbø wrote:
>> I would not want to have those “you’re using a fast, but not optimal version 
>> of the N string classes” warnings unless I was writing string heavy and 
>> performance sensitive code.
> 
> So just use QString :-)

You mean foo[QString(“bar”)] = QString(“baz”)?

That’s already two QStrings too much  

> 
>> And if we can have the compiler automatically make the right choice for us 
>> we wouldn’t need any of those.
> 
> That's another "time machine" kind of thing.

Is it? For Qt 6?

> 
> 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] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 18:30, Thiago Macieira  wrote:
> 
> On Wednesday, 21 August 2019 09:17:24 PDT Tor Arne Vestbø wrote:
>>> Remember that QStringLiteral today has a drawback: if you 
>>> unload the plugin it came from, any left-over uses of it may crash. That's
>>> one  of the many reasons we don't unload plugins, but other people
>>> might.
>> 
>> Is that the only drawback? Is that the only reason we’re not doing it?
> 
> With a proper Qt 6 implementation, yes. Not right now in Qt 5, there are a 
> few 
> more.

Qt 6 is fine  That would be great!

> 
>> On macOS plugins are never unloaded. Could the behaviour be dependent on
>> whether or not we’re building a plugin?
> 
> All macOS plugins or just *our* plugins? QPluginLoader doesn't unload, but 
> QLibrary does.

I have to double check the dyld sources, but in many cases the dlclose will be 
a no-op, and the image won’t actually unload. One of these conditions was (if I 
recall correctly) if the library had any thread local storage. 

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Giuseppe D'Angelo via Development


On 21/08/2019 18:21, Tor Arne Vestbø wrote:

I would not want to have those “you’re using a fast, but not optimal version of 
the N string classes” warnings unless I was writing string heavy and 
performance sensitive code.


So just use QString :-)


And if we can have the compiler automatically make the right choice for us we 
wouldn’t need any of those.


That's another "time machine" kind of thing.

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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 09:17:24 PDT Tor Arne Vestbø wrote:
> > Remember that QStringLiteral today has a drawback: if you 
> > unload the plugin it came from, any left-over uses of it may crash. That's
> > one  of the many reasons we don't unload plugins, but other people
> > might.
> 
> Is that the only drawback? Is that the only reason we’re not doing it?

With a proper Qt 6 implementation, yes. Not right now in Qt 5, there are a few 
more.

> On macOS plugins are never unloaded. Could the behaviour be dependent on
> whether or not we’re building a plugin?

All macOS plugins or just *our* plugins? QPluginLoader doesn't unload, but 
QLibrary does.

We can force a plugin not to allow unloading, with the -z nodelete linker 
flag. Works on ELF systems, I don't know about Mach-O.

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 09:19:26 PDT Konstantin Tokarev wrote:
> 21.08.2019, 19:02, "Thiago Macieira" :
> > On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
> >>  I hope that standard committee will never introduce implicit generation
> >> of
> >>  UTF16 literals from C string literals.
> > 
> > You're over 10 years too late. That's exactly what u"" does.
> 
> That's explicit request, not implicit.

With constexpr we can do the conversion ourselves. We don't need the committee 
to do it for us.

-- 
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] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 18:01, Thiago Macieira  wrote:
> 
> On Wednesday, 21 August 2019 08:49:52 PDT Tor Arne Vestbø wrote:
>> I agree that this would mitigate the problem somewhat, but imagine writing
>> your code and being reminded every second:
> 
>>   warning: using “foo" is not optimal, you should be using
>> QEsotericLiteralStringViewV2NG
> 
> is that worse than Creator showing in yellow that "warning: comparison of 
> integers of different signs: unsigned long and int" ?
> 
> Or "macro name is a reserved identifier" in
> #define _GNU_SOURCE

Depends on your chosen warning level I guess. If you want -Wall -Wpedantic 
-Wextra ++ then sure, that’s what you’d expect. 

I would not want to have those “you’re using a fast, but not optimal version of 
the N string classes” warnings unless I was writing string heavy and 
performance sensitive code.

And if we can have the compiler automatically make the right choice for us we 
wouldn’t need any of those.

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

Re: [Development] HEADS-UP: QStringLiteral



21.08.2019, 19:02, "Thiago Macieira" :
> On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
>>  I hope that standard committee will never introduce implicit generation of
>>  UTF16 literals from C string literals.
>
> You're over 10 years too late. That's exactly what u"" does.
>

That's explicit request, not implicit.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 17:58, Thiago Macieira  wrote:
> 
> On Wednesday, 21 August 2019 08:16:42 PDT Tor Arne Vestbø wrote:
>> That’s what I was hoping. We have QFooLiteral today to let the compiler do
>> the work up front, isn’t it possible with newer c++ standards to have that
>> happen automatically without an explicit QFooLiteral?
> 
> Yes, it's possible.
> 
> But do we want to?

Yes :)

> Remember that QStringLiteral today has a drawback: if you 
> unload the plugin it came from, any left-over uses of it may crash. That's 
> one 
> of the many reasons we don't unload plugins, but other people might.

Is that the only drawback? Is that the only reason we’re not doing it?

On macOS plugins are never unloaded. Could the behaviour be dependent on 
whether or not we’re building a plugin?

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

Re: [Development] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 08:49:52 PDT Tor Arne Vestbø wrote:
> I agree that this would mitigate the problem somewhat, but imagine writing
> your code and being reminded every second:
 
>warning: using “foo" is not optimal, you should be using
> QEsotericLiteralStringViewV2NG
 
is that worse than Creator showing in yellow that "warning: comparison of 
integers of different signs: unsigned long and int" ?

Or "macro name is a reserved identifier" in
#define _GNU_SOURCE

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
> I hope that standard committee will never introduce implicit generation of
> UTF16 literals from C string literals.

You're over 10 years too late. That's exactly what u"" does.

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 08:16:42 PDT Tor Arne Vestbø wrote:
> That’s what I was hoping. We have QFooLiteral today to let the compiler do
> the work up front, isn’t it possible with newer c++ standards to have that
> happen automatically without an explicit QFooLiteral?

Yes, it's possible.

But do we want to? Remember that QStringLiteral today has a drawback: if you 
unload the plugin it came from, any left-over uses of it may crash. That's one 
of the many reasons we don't unload plugins, but other people might.

Requiring heap storage avoids that problem. And if we know that it's always 
heap storage, we can also simplify our memory management code by not having 
immutable d-pointers either.

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 08:18:08 PDT Tor Arne Vestbø wrote:
> > Oh, the following is nearly the most optimal:
> > 
> > 
> > test[u"key"] = u"value”;
> 
> 
> So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie
> u8”foo” without the explicitness?

We can and already do that. But that's not optimal, since the UTF-8 algorithm 
has a cost.

That's why we are not removing QLatin1String: the Latin1 algorithm is as fast 
as memcpy. The only thing better than that is zero copies.
-- 
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] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 17:39, Giuseppe D'Angelo via Development 
>  wrote:
> 
> However, what I was referring about was the problem of using the wrong class 
> to manage string-data: if tooling can reliably tell users that they're doing 
> a mistake, this drastically reduces the chances of such mistakes happening 
> (and the associated cognitive load). As such, then having many classes 
> becomes a less important issue (because a tool will tell you if you're using 
> the wrong one).

I agree that this would mitigate the problem somewhat, but imagine writing your 
code and being reminded every second:

   warning: using “foo" is not optimal, you should be using 
QEsotericLiteralStringViewV2NG



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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Giuseppe D'Angelo via Development


On 21/08/2019 13:19, Bogdan Vatra wrote:

   Holy mother of sweet Jesus Christ, are you calling these "minor issues" ?!?!
Are you insane ? :)


Sorry, let me clarify: the huge amount of classes and facilities in Qt 
and C++ for string handling is an issue, and a major one. If anything, 
teachability of all these options (which are in constant evolution) is a 
big problem.


However, what I was referring about was the problem of using the wrong 
class to manage string-data: if tooling can reliably tell users that 
they're doing a mistake, this drastically reduces the chances of such 
mistakes happening (and the associated cognitive load). As such, then 
having many classes becomes a less important issue (because a tool will 
tell you if you're using the wrong one).



   I don't think there is any tooling smart enough to detect*ALL*  the
situations. In previous examples I used only QLatin1String and QStringLiteral
let's not forget that there are many more: QString::fromX, QStringView,
and probably more that I don't know about.
   THB I don't think tooling is the right answer here, I'm still dreaming to a
single simple and nice string class and maybe*one*  wrapper*if*  is really
needed.


Possibly, but that requires a time machine.

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] HEADS-UP: QStringLiteral



21.08.2019, 18:29, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 17:24, Konstantin Tokarev  wrote:
>>
>>  21.08.2019, 18:22, "Tor Arne Vestbø" :
   On 21 Aug 2019, at 16:55, Thiago Macieira  
 wrote:

   On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>   On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>   This should just be test[“key”] = “value”. How do we get there?
>
>   Do you mean "make this the most optimal?" If so, then we don't get 
> there.
>   It's not possible.

   Oh, the following is nearly the most optimal:

   test[u"key"] = u"value”;
>>>
>>>  So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
>>> u8”foo” without the explicitness?
>>
>>  Conversion of UTF8 to UTF16 costs more, and here we know that literal is 
>> ASCII-only.
>
> Sure, okey, I’m happy with “foo” being interpreted as ascii, u8”" as utf8 and 
> u”” as utf16, as long as I can use all of them in other Qt APIs that take a 
> stringish. Ideally with automatic make-it-a-qstring-literal using C++ 
> fanciness over QFooLiteral :)

I would prefer if Qt APIs didn't insist on using QString and could work with 
sane string encodings

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 17:24, Konstantin Tokarev  wrote:
> 
> 
> 
> 21.08.2019, 18:22, "Tor Arne Vestbø" :
>>>  On 21 Aug 2019, at 16:55, Thiago Macieira  
>>> wrote:
>>> 
>>>  On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>  This should just be test[“key”] = “value”. How do we get there?
 
  Do you mean "make this the most optimal?" If so, then we don't get there.
  It's not possible.
>>> 
>>>  Oh, the following is nearly the most optimal:
>>> 
>>>  test[u"key"] = u"value”;
>> 
>> So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
>> u8”foo” without the explicitness?
> 
> Conversion of UTF8 to UTF16 costs more, and here we know that literal is 
> ASCII-only.

Sure, okey, I’m happy with “foo” being interpreted as ascii, u8”" as utf8 and 
u”” as utf16, as long as I can use all of them in other Qt APIs that take a 
stringish. Ideally with automatic make-it-a-qstring-literal using C++ fanciness 
over QFooLiteral :)

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

Re: [Development] HEADS-UP: QStringLiteral



21.08.2019, 18:22, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 16:55, Thiago Macieira  wrote:
>>
>>  On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>>>  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
  This should just be test[“key”] = “value”. How do we get there?
>>>
>>>  Do you mean "make this the most optimal?" If so, then we don't get there.
>>>  It's not possible.
>>
>>  Oh, the following is nearly the most optimal:
>>
>>  test[u"key"] = u"value”;
>
> So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
> u8”foo” without the explicitness?

Conversion of UTF8 to UTF16 costs more, and here we know that literal is 
ASCII-only.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral



21.08.2019, 18:19, "Tor Arne Vestbø" :
>>  On 21 Aug 2019, at 16:47, Thiago Macieira  wrote:
>>
>>  On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>>  This should just be test[“key”] = “value”. How do we get there?
>>
>>  Do you mean "make this the most optimal?" If so, then we don't get there. 
>> It's
>>  not possible.
>
> Optimal enough :) With a way to micro-optimise it using a more explicit API 
> i needed.
>
>>  We could do it for literals with some constexpr help in the QString
>
> That’s what I was hoping. We have QFooLiteral today to let the compiler do 
> the work up front, isn’t it possible with newer c++ standards to have that 
> happen automatically without an explicit QFooLiteral?

I hope that standard committee will never introduce implicit generation of 
UTF16 literals from C string literals.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 16:55, Thiago Macieira  wrote:
> 
> On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
>> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>>> This should just be test[“key”] = “value”. How do we get there?
>> 
>> Do you mean "make this the most optimal?" If so, then we don't get there.
>> It's not possible.
> 
> Oh, the following is nearly the most optimal:
> 
>   test[u"key"] = u"value”;

So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie 
u8”foo” without the explicitness?

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

Re: [Development] HEADS-UP: QStringLiteral

> On 21 Aug 2019, at 16:47, Thiago Macieira  wrote:
> 
> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
>> This should just be test[“key”] = “value”. How do we get there?
> 
> Do you mean "make this the most optimal?" If so, then we don't get there. 
> It's 
> not possible.

Optimal enough :) With a way to micro-optimise it using a more explicit API 
i needed.

> We could do it for literals with some constexpr help in the QString 

That’s what I was hoping. We have QFooLiteral today to let the compiler do the 
work up front, isn’t it possible with newer c++ standards to have that happen 
automatically without an explicit QFooLiteral?

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

Re: [Development] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
> > This should just be test[“key”] = “value”. How do we get there?
> 
> Do you mean "make this the most optimal?" If so, then we don't get there.
> It's not possible.

Oh, the following is nearly the most optimal:

test[u"key"] = u"value";

Depending on what tricks we do to QString, we can make it most optimal. In Qt 
5, we did it with QStringLiteral. For Qt 6, if we retain QStringLiteral, it 
would be a special QString that has immutable data.

We can experiment to see what C++17 std::is_constant_evaluated() allows us to 
guess.

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
> This should just be test[“key”] = “value”. How do we get there?

Do you mean "make this the most optimal?" If so, then we don't get there. It's 
not possible.

We could do it for literals with some constexpr help in the QString 
constructor, but the equivalent code

const char *key = "key";
const char *value = "value";
test[key] = value;

would not be optimal.

-- 
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] HEADS-UP: QStringLiteral

On Wednesday, 21 August 2019 00:50:01 PDT Jean-Michaël Celerier wrote:
> > Try *any* other compiler and you'll see there's no mutex.
> 
> Don't __cxa_guard_acquire / release use at least futexes ? I'd wager that
> in a non-zero amount of applications, having *any* kind of  syscalls or
> locks sprinkled here and there
> depending on whether you use "static" or not is not kosher (I'd also wager
> that these applications wouldn't be using Qt anyways... except maybe the
> ones using that safe renderer thing ?).

They do, but my point is that there is no guard acquire or release. The static 
in the QStringLiteral lambda is constexpr.

-- 
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] Accelerating deprecation of MSVC 2017

On Wednesday, 21 August 2019 05:31:55 PDT Alex Blasche wrote:
> What is the hurry for this decision? Generally, we look at download figures
> as base line and decide based on them. Thiago, are we currently facing
> issues where we cannot further fix/work around problems or is this request
> closer to the nice-to-have camp? We'd need a reason why we potentially want
> to annoy half the people downloading Qt on Windows. Note that I don't know
> what the current download figures and just want to highlight the Qt user's
> perspective.

Because 5.15 is LTS, I'd like to make sure we don't lock ourselves to MSVC 
2017 until 2023, when that compiler will be coming up on 6 years of age.

We should be doing this exercise for all compilers we support. It just 
occurred to me to send this about MSVC because of the mutex-on-statics 
discussion in the QStringView thread.

-- 
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] HEADS-UP: QStringLiteral

2019-08-21 Thread Mutz, Marc via Development

On 2019-08-21 14:13, Sérgio Martins via Development wrote:

On 2019-08-20 16:56, Bogdan Vatra via Development wrote:

Hi,

Isn't silly to have so many wrappers around a such a simple thing as
strings? All the major frameworks out there (i.e. Java, C#) they have
a single

String which does all the magic.

We do have a single one that does all the magic: QString. A Qt user
can ignore all others.

Ack.

The difference between Qt and Java or C# is that we also offer
non-allocating alternatives for users who care. And if they care, they
need to learn them.

Another difference is that, in Java at least (or was it JavaScript?),
"foo" _is_ a String (as in "foo".length()). This is decidedly not the
case in C++/Qt. In Java, the compiler can place "foo" into read-only
memory, and it will be an (immutable, as I learned) String instance.
It's probably also the case that all "foo" in the same program are the
same string. All this is, or at least may be, also the case for "foo" in
C++, except that "foo" is not a std::string or QString instance. C++ has
no concept of strings. Only of string literals. "foo" is a const
char[4]. To manipulate it, you need to use malloc/strdup/strcpy, or you
must copy the data into a user-defined class such as std::string or
QString. We can lament this over and over again, but it will not change
the facts. QStringLiteral is an attempt at fixing this: a fully-fledged
QString, but placed in read-only memory, no runtime allocations. The
problem is that the way it's implemented, QStringLiteral("foo") +
QStringLiteral("foo") stores the string u"foo" and its QStringData
header, _twice_ in the executable. And since we globally enabled
QStringBuilder, there's no runtime efficiency difference to
QLatin1String("foo") + QLatin1String("foo") which _will_ store "foo"
just once.

For the case that triggered this discussion, the androiddeployqt
executable, I wouldn't bother with optimizations and just use what's
more readable, even raw strings.

I agree in principle. The problem in Qt code is that it's mostly
library, and making checkers (and reviewers) aware of the type of source
code will be extra work compared to just applying the same rules
everywhere. After all, this is decidedly not optimisation, it's avoiding
pessimisation, and as such, the non-pessimised version of the code
should naturally flow from your fingers. It should take extra mental
work to unlearn the library rules when coding on a tool for once.

And:

Code gets copied: this is from a tool:

https://codereview.qt-project.org/c/qt/qt3d/+/263442/2/tools/qgltf/qgltf.cpp

this was later found in a plugin:

https://codereview.qt-project.org/c/qt/qt3d/+/268271/2/src/plugins/sceneparsers/assimp/assimphelpers.cpp

So while I totally agree that in application code, do as you want, the
advice is not quite so clear-cut for Qt tools, or, in fact, any project
where the same developers are working on a library as well as tools.

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

Re: [Development] Accelerating deprecation of MSVC 2017

2019-08-21 Thread Alex Blasche



> -Original Message-
> From: Development  On Behalf Of
> Edward Welbourne
> Sent: Wednesday, 21 August 2019 11:15
> To: Konstantin Tokarev 
> Cc: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] Accelerating deprecation of MSVC 2017
> 
> 21.08.2019, 00:45, "Thiago Macieira" :
> >>> I'd like to propose we announce now that it will not be supported
> >>> for Qt 5.15.
> 
> Certainly if we can persuade ourselves now that this will be prudent then, we
> should announce our intent as soon as we make up our minds.
>
> >>> Even if 2019 still has code generation problems.
> 
> ... today, when we're making the decision.  If MS somehow manage not to fix
> them before we release 5.15, we can always change our minds.

I think this is a bit too simplistic. If we decide now, reality tends to have a 
way of ensuring that we cannot change our minds. Developers tend to quickly 
jump at opportunities offered by the fact that compilers are dropped and 
utilize further features of the newer compiler. Therefore, turning back could 
be more significant work.

What is the hurry for this decision? Generally, we look at download figures as 
base line and decide based on them. Thiago, are we currently facing issues 
where we cannot further fix/work around problems or is this request closer to 
the nice-to-have camp? We'd need a reason why we potentially want to annoy half 
the people downloading Qt on Windows. Note that I don't know what the current 
download figures and just want to highlight the Qt user's perspective.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Sérgio Martins via Development


On 2019-08-20 16:56, Bogdan Vatra via Development wrote:

Hi,

  Isn't silly to have so many wrappers around a such a simple thing as
strings? All the major frameworks out there (i.e. Java, C#) they have a 
single

String which does all the magic.


We do have a single one that does all the magic: QString. A Qt user can 
ignore all others.


The difference between Qt and Java or C# is that we also offer 
non-allocating alternatives for users who care. And if they care, they 
need to learn them.


For the case that triggered this discussion, the androiddeployqt 
executable, I wouldn't bother with optimizations and just use what's 
more readable, even raw strings.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: QStringLiteral

>> Returning to your original post:
> All the major frameworks out there (i.e. Java, C#) they have a
> single String which does all the magic.
>>
>> Yes, and those systems are all built with the assumption that client
>> code doesn't care if every single time anything happens to a string a
>> fresh copy of it is made.  They probably aren't actually that
>> inefficient, but the basic premise of the design of those easy-to-use
>> string classes is that if they were it wouldn't matter much.

Bogdan Vatra (21 August 2019 13:28) replied:
> When I say framework, I actually mean the framework code not the
> client code.  Let's take the java classes from Android, can you please
> show me a single place where Android folk are using some strange:
> String myString = StringLiteral("string") instead of a simple String
> myString = "string"; ?

Indeed, because Java (and others) have opted to care more about ease of
use than efficiency, their strings are easier to use.

>> We don't have that luxury, sad to say,

> But we have the luxury to loose potential Qt contributors because we
> are going to force them to use so many string wrappers?

We'd rather not - and hence the present discussion thread - how do we do
better than the present tangled mess ? - which I entirely agree is a mess:
the fact that we need to add [0]'s account of when to use which to our
docs is a testament to how confusing the present situation is.

* [0] https://codereview.qt-project.org/c/qt/qtdoc/+/268079

It remains that solving the problem is hard.  One of the things folk
want is a data() method on a string that lets them get at the raw data
and do as they please to it; this forces the string type to store its
data in the encoding that the data() method returns - UTF-16.  Having
done that, all other types of data must be converted to that encoding,
when constructing a string.  That means literals in source code either
are in UTF-16 (in which case, if their content can be expressed in pure
ASCII, the literal takes up twice as much memory in the binary as it
really needs) or have to be converted at run-time; either of these is a
cost one may reasonably prefer to avoid.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Elvis Stansvik

Den ons 21 aug. 2019 kl 12:22 skrev Lars Knoll :
>
>
> > On 21 Aug 2019, at 13:01, Tor Arne Vestbø  wrote:
> >
> >
> >
> >> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development 
> >>  wrote:
> >>
> >> Am I the only one which finds situations silly ? Of course there are more
> >> examples with the other String wrappers/functions in Qt, but I think is 
> >> enough
> >> to show how crazy is the situation.
> >
> > You are not!
> >
> > I completely agree, and I think it’s a detriment to Qt’s promise of easy to 
> > use APIs that these optimised versions are not automagic and hidden behind 
> > the scenes, or don’t have a clear cut story for when to explicitly use.
>
> +1. Things are getting overly complex. And in the end most people will write 
> less optimal code simply because they do now know which class is the best to 
> use in which use case. If people on this list are confused, you can be 
> certain that 98% of our users will not get the subtle differences.

I'm in that category of users. I've never even bothered to learn what
the non-QString stuff (QLatin1Literal, QStringLiteral, ...) about,
despite it having been around for quite a while and me knowing about
their existance, and just use QString or "" everywhere. This is
non-optimal but I do it because, because a) it's less to type and
read, b) string operations has never been a bottleneck in the
applications I've worked on and c) it's one less set of rules I (and
my coworkers) have to remember. The situations is probably different
for library developers (e.g. Qt developers), which have to strive for
optimality (within reason).

Elvis

> >
> >> // Even more
> >> QHash test;
> >> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // 
> >> wrong
> >> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // 
> >> wrong
> >> again
> >> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
> >> still
> >> wrong
> >> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> >> victory !!!
> >
> > This should just be test[“key”] = “value”. How do we get there?
>
> One way would be by enforcing utf8 as source encoding for Qt based projects. 
> It’s a huge shame that C++ doesn’t specify the encoding of source code as 
> opposed to pretty much any other programming language (hell even JS got that 
> one right…).
>
> So I think it might be worthwhile enforcing that for Qt 6. But it leaves the 
> question of what to do with QL1String.
>
> Cheers,
> Lars
>
> ___
> 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] HEADS-UP: QStringLiteral

2019-08-21 Thread Bogdan Vatra via Development

Hi,

> Returning to your original post:
> >>> All the major frameworks out there (i.e. Java, C#) they have a
> >>> single String which does all the magic.
> 
> Yes, and those systems are all built with the assumption that client
> code doesn't care if every single time anything happens to a string a
> fresh copy of it is made.  They probably aren't actually that
> inefficient, but the basic premise of the design of those easy-to-use
> string classes is that if they were it wouldn't matter much.
> 

When I say framework, I actually mean the framework code not the client code. 
Let's take the java classes from Android, can you please show me a single 
place where Android folk are using some strange: String myString = 
StringLiteral("string") instead of a simple String myString = "string"; ?

> We don't have that luxury, sad to say,
> 

But we have the luxury to loose potential Qt contributors because we are going 
to force them to use so many string wrappers?

Cheers,
BogDan.


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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Shawn Rutledge



On 21 Aug 2019, at 12:38, Edward Welbourne 
mailto:edward.welbou...@qt.io>> wrote:

On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote:

All the major frameworks out there (i.e. Java, C#) they have a
single String which does all the magic.

Yes, and those systems are all built with the assumption that client
code doesn't care if every single time anything happens to a string a
fresh copy of it is made.

In Java, String is immutable, and often “interned”, in which case there are no 
copies of any two strings that have the same bytes.
https://stackoverflow.com/questions/10578984/what-is-java-string-interning

But concatenating multiple immutable strings will make a new one, and the old 
ones could be garbage if you no longer keep references to them; so there are 
StringBuilder and StringBuffer, as workarounds to make that faster.  And then 
the compiler got smarter: 
https://stackoverflow.com/questions/1532461/stringbuilder-vs-string-concatenation-in-tostring-in-java

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Bogdan Vatra via Development

Hi,
În ziua de miercuri, 21 august 2019, la 13:53:02 EEST, Giuseppe D'Angelo via 
Development a scris:
> Hi,
> 
> On 21/08/2019 11:50, Bogdan Vatra via Development wrote:
> >Personally I'm not going to waste my time learning 10 sting wrappers
> >and
> > 
> > classes just to make some pico optimizations like:
> > 
> > QString ext = QLatin1String("exe"); // it's terribly wrong and people
> > which
> > are doing this mistake must be stoned to death!
> > 
> > QString ext = QStringLiteral("exe"); // it's so good and it will save the
> > planet from extinction!
> > 
> > // But
> > QString ext1 = QLatin1String("exe") + ext; // it's ok
> > // and
> > QString ext = QStringLiteral("exe") + ext; // it's a abomination!
> > 
> > // Even more
> > QHash test;
> > test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); //
> > wrong test[QStringLiteral("key1")] = QStringLiteral("some text
> > %1").arg(1); // wrong again
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> > still wrong
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> > victory !!!
> 
> How many of these are "mistakes" detectable by tooling? Because if they
> are, they're a very minor issue.
>

  Holy mother of sweet Jesus Christ, are you calling these "minor issues" ?!?! 
Are you insane ? :)

  I don't think there is any tooling smart enough to detect *ALL* the 
situations. In previous examples I used only QLatin1String and QStringLiteral 
let's not forget that there are many more: QString::fromX, QStringView, 
and probably more that I don't know about.
  THB I don't think tooling is the right answer here, I'm still dreaming to a 
single simple and nice string class and maybe *one* wrapper *if* is really 
needed.

Cheers,
BogDan.


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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Ville Voutilainen

On Wed, 21 Aug 2019 at 13:23, Lars Knoll  wrote:
> One way would be by enforcing utf8 as source encoding for Qt based projects. 
> It’s a huge shame that C++ doesn’t specify the encoding of source code as 
> opposed to pretty much any other programming language (hell even JS got that 
> one right…).

You can ask the SG16 folks for more details, but it's wa too
soon to make such a break. There are very serious users
whose source code is EBCDIC. In a nutshell, C++ has supported multiple
source encodings for a long time, and users rely
on that. So sure, it's a shame, but the shame can hardly be avoided by
anything else besides a time machine.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Accelerating deprecation of MSVC 2017

2019-08-21 Thread Harald Kjølberg

 
 > > No, I recommend using 2019 because MS will fix it. 2015 is no longer 
 > > supported in 5.13.

 >Is this really so? We even deliver MSVC 2015 binaries. @Harald?

As far as I know, we stopped delivering 32-bit binaries for MSVC2015 (replacing 
them with MSVC2017) in Qt 5.13, but the 64-bit version is still there. As it 
makes no sense to keep unsupported compilers, we have acted on the suggestion 
of removing MSVC2015 completely from Qt 5.14. See 
https://bugreports.qt.io/browse/QTQAINFRA-3154

Cheers,
Harald


   >-T




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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Giuseppe D'Angelo via Development


Hi,

On 21/08/2019 11:50, Bogdan Vatra via Development wrote:


   Personally I'm not going to waste my time learning 10 sting wrappers and
classes just to make some pico optimizations like:

QString ext = QLatin1String("exe"); // it's terribly wrong and people which
are doing this mistake must be stoned to death!

QString ext = QStringLiteral("exe"); // it's so good and it will save the
planet from extinction!

// But
QString ext1 = QLatin1String("exe") + ext; // it's ok
// and
QString ext = QStringLiteral("exe") + ext; // it's a abomination!

// Even more
QHash test;
test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong
again
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
wrong
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
victory !!!


How many of these are "mistakes" detectable by tooling? Because if they 
are, they're a very minor issue.


Thanks,
--
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] HEADS-UP: QStringLiteral

On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote:
>>> Isn't silly to have so many wrappers around a such a simple thing as
>>> strings?

În ziua de miercuri, 21 august 2019, la 00:12:59 EEST, Thiago Macieira a scris:
>> We all wish it were simple. If it were, we would have no need for so
>> many string classes, for Marc's email and even for SG16 (Unicode) to
>> exist in the C++ committee.

To elaborate: designing a good string class Is Hard.

I've seen text-books by academics who cheerfully take on the task as a
nice example that everyone can understand by which to show off how their
language of choice does a fine job of object-orientation.  They
invariably reveal how little they know about the practicalities of class
design in production environments: the results would be slow, hog memory
and fail to work across threads.  All too often it's assumed that making
a few dozen copies of all your data in the course of a single line of
code is inconsequential.

I've worked with several string classes "in industry" that have been
honed to be tolerably efficient.  All come with annoying amounts of
advice one has to remember about how to use them to avoid wanton
allocation of yet more copies of one's data.  All make compromises
between efficiency and ease of use.  Still, they worked better than the
ones the academics proposed.

Furthermore, what this thread is discussing isn't just string classes;
although QByteArray has some inappropriately string-ish features bolted
into it, it's really a *container* class for carrying around a slab of
data.  That this data is often meant to be interpreted as a string
should be the business of some string-view facade on top of it, that the
data container shouldn't care about.  The difference is crucial: a byte
array just contains bytes, without interpretation; by applying some
encoding, other code may interpret it as a string and might even
reasonably use it as the data-store backing a string facade that does
this interpretation; but the byte array isn't a string.

Bogdan Vatra (21 August 2019 11:50)
> You didn't answered my questions :).

I hope the above goes some way towards doing that.

>   The most important one is: can we have *A single* String class and
> *A* single sting wrapper for each UTF-X variant?

Partly because we're where we are and it's hard to change - replacing
QString in all of Qt would be impractical.  However, see above:
designing a Good string class Is Hard.  Asking for nice features that it
should have is easy; and quite quickly constrains it to be almost
impossible to implement, once one actually works out all the conflicting
implications of all the nice features we all want.

>   Personally I'm not going to waste my time learning 10 sting wrappers
> and classes just to make some pico optimizations like:
>
> QString ext = QLatin1String("exe"); // it's terribly wrong and people
> which are doing this mistake must be stoned to death!
>
> QString ext = QStringLiteral("exe"); // it's so good and it will save
> the planet from extinction!
>
> // But
> QString ext1 = QLatin1String("exe") + ext; // it's ok
> // and
> QString ext = QStringLiteral("exe") + ext; // it's a abomination!
>
> // Even more
> QHash test;
> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong
> again
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
> wrong
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> victory !!!

I fail to find a difference between the last two !
But I grant that you have made your point.

> Am I the only one which finds situations silly ? Of course there are
> more examples with the other String wrappers/functions in Qt, but I
> think is enough to show how crazy is the situation.

Yes, it is frustrating and annoying that one has to learn all these
fiddly details and apply them; and yes, it would be nice if there were
one master string class to rule all others, that folk can use when they
don't care too much about efficiency.  Perhaps the answer to that is to
use PySide / PyQt, hence python's string types.

It is frustrating, but it is not silly: it is that way for the sake of
performance and efficiency.  In client code, you can do as you please
and just use QString("whatever") freely.  However, in library code,
those of us who develop Qt have a duty, to clients who *do* care about
performance, to actually think about all these fiddly little
complications, that can have significant impact on code footprint,
run-time memory use and speed.

Returning to your original post:
>>> All the major frameworks out there (i.e. Java, C#) they have a
>>> single String which does all the magic.

Yes, and those systems are all built with the assumption that client
code doesn't care if every single time anything happens to a string a
fresh copy of it is made.  They probably aren't actually that

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Lars Knoll


> On 21 Aug 2019, at 13:01, Tor Arne Vestbø  wrote:
> 
> 
> 
>> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development 
>>  wrote:
>> 
>> Am I the only one which finds situations silly ? Of course there are more 
>> examples with the other String wrappers/functions in Qt, but I think is 
>> enough 
>> to show how crazy is the situation.
> 
> You are not! 
> 
> I completely agree, and I think it’s a detriment to Qt’s promise of easy to 
> use APIs that these optimised versions are not automagic and hidden behind 
> the scenes, or don’t have a clear cut story for when to explicitly use.

+1. Things are getting overly complex. And in the end most people will write 
less optimal code simply because they do now know which class is the best to 
use in which use case. If people on this list are confused, you can be certain 
that 98% of our users will not get the subtle differences.
> 
>> // Even more
>> QHash test;
>> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
>> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // 
>> wrong 
>> again
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
>> still 
>> wrong
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
>> victory !!!
> 
> This should just be test[“key”] = “value”. How do we get there?

One way would be by enforcing utf8 as source encoding for Qt based projects. 
It’s a huge shame that C++ doesn’t specify the encoding of source code as 
opposed to pretty much any other programming language (hell even JS got that 
one right…). 

So I think it might be worthwhile enforcing that for Qt 6. But it leaves the 
question of what to do with QL1String.

Cheers,
Lars

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Jaroslaw Kobus

I propose the following policy regarding any further new string classes / 
wrappers in Qt:

Whenever anyone propose new string class / wrapper in public API of Qt, he is 
obligated to deprecate in parallel at least 2 other string classes / wrappers 
in public API of Qt.

Regards

Jarek

From: Development  on behalf of Tor Arne 
Vestbø 
Sent: Wednesday, August 21, 2019 12:01 PM
To: Bogdan Vatra
Cc: Thiago Macieira; Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral

> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development 
>  wrote:
>
> Am I the only one which finds situations silly ? Of course there are more
> examples with the other String wrappers/functions in Qt, but I think is enough
> to show how crazy is the situation.

You are not!

I completely agree, and I think it’s a detriment to Qt’s promise of easy to use 
APIs that these optimised versions are not automagic and hidden behind the 
scenes, or don’t have a clear cut story for when to explicitly use.

> // Even more
> QHash test;
> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong
> again
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still
> wrong
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> victory !!!

This should just be test[“key”] = “value”. How do we get there?

Tor Arne
___
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] HEADS-UP: QStringLiteral



> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development 
>  wrote:
> 
> Am I the only one which finds situations silly ? Of course there are more 
> examples with the other String wrappers/functions in Qt, but I think is 
> enough 
> to show how crazy is the situation.

You are not! 

I completely agree, and I think it’s a detriment to Qt’s promise of easy to use 
APIs that these optimised versions are not automagic and hidden behind the 
scenes, or don’t have a clear cut story for when to explicitly use.

> // Even more
> QHash test;
> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // 
> wrong 
> again
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still 
> wrong
> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
> victory !!!

This should just be test[“key”] = “value”. How do we get there?

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Bogdan Vatra via Development

Hi,

În ziua de miercuri, 21 august 2019, la 00:12:59 EEST, Thiago Macieira a 
scris:
> On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote:
> >   Isn't silly to have so many wrappers around a such a simple thing as
> > 
> > strings?
> 
> We all wish it were simple. If it were, we would have no need for so many
> string classes, for Marc's email and even for SG16 (Unicode) to exist in the
> C++ committee.

You didn't answered my questions :).
  The most important one is: can we have  *A single* String class and *A* 
single sting wrapper for each UTF-X variant?

  Personally I'm not going to waste my time learning 10 sting wrappers and 
classes just to make some pico optimizations like:

QString ext = QLatin1String("exe"); // it's terribly wrong and people which 
are doing this mistake must be stoned to death!

QString ext = QStringLiteral("exe"); // it's so good and it will save the 
planet from extinction!

// But
QString ext1 = QLatin1String("exe") + ext; // it's ok
// and 
QString ext = QStringLiteral("exe") + ext; // it's a abomination!

// Even more
QHash test;
test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong 
again
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still 
wrong
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
victory !!!

Am I the only one which finds situations silly ? Of course there are more 
examples with the other String wrappers/functions in Qt, but I think is enough 
to show how crazy is the situation.

Cheers,
BogDan.

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

Re: [Development] HEADS-UP: QStringLiteral

Thiago Macieira (20 August 2019 23:11)
> [*] untested with ICC on Windows and with INTEGRITY's compiler. It's
> assumed that they do and if they don't, it's a compiler bug.

which, none the less, is apt to block integration - as the QCalendar
commit suffered on its way in, with INTEGRITY not handling "using"
like the rest do.

By the way, Qt 5.14 now includes QCalendar :-)

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

Re: [Development] Accelerating deprecation of MSVC 2017