subject:"\[Development\] HEADS\-UP\: QStringLiteral"

On Thursday, 22 August 2019 14:41:51 PDT Matthew Woehlke wrote:
> On 22/08/2019 17.00, Thiago Macieira wrote:
> > For Qt 6, it is possible (and is still my goal[*]) to make creating a
> > QString out of a QStringView and through it from a u"" literal happen
> > in constant time, inlined, with no memory allocation.
> 
> How? Unless I miss something (which your example did not show),
> QStringView doesn't know if the memory to which it points is rodata or
> something else. If it's something else, you can't just stick it in a
> QString and hope for the best, because it could change or cease to be
> allocated at any time.

You're right, it can't be done through QStringView. Only from the origina; 
literal, via the trick in GCC (the same that they used for 
std::char_traits::length()) that allows us to determine if it's a string 
literal. 

Another idea that has occurred to me is to extend QStringView to carry a non-
null d-pointer (without reference counting it) whenever it's created from a 
QString. That way, creating a QString from a QStringView that was created from 
a QString resumes the reference counting.
-- 
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 Thursday, 22 August 2019 14:43:48 PDT Ville Voutilainen wrote:
> > In any case, we could advocate for utf8 being the input encoding when
> > writing Qt based code/projects or even make it the default. I wanted to
> > do that for Qt 5.0, but we couldn’t because MSVC didn’t support it at
> > that time. It does now however.
> I must wonder.. are the benefits of that really that useful? I suppose
> it's nice that you can just write utf-8 in your plain literals, but I
> wonder why
> a u"literal" is overly burdensome.

It's not.

The point is that you can't write u"Fußball Résumé" unless the source file is 
encoded in UTF-8, if you hope to share it with other people.

You'd have to write u"Fu\u00DFball R\u00E9sum\u00E9".

PS: to write "ß" and "é", I type  and   respectively. 
to type "\u00DF" and "\u00E9", I opened kcharselect, typed the characters that 
I already knew I wanted and searched. 

PPS: I can type "ę", "°", "ª", "€", "£", "¥", "č", "ā", "æ", "©", "™", "⁴" 
with just the keyboard. "us(alt-intl)+latin" rules.

-- 
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-22 Thread Kevin Kofler

Tor Arne Vestbø wrote:
> Yes, clearly these are equal in readability:
[I sense your sarcasm. ;-) ]
> 
> if (std::find(v.begin(), v.end(), x) != v.end())
> 
> if (v.contains(x))

Thank you for this great example of how unreadable and unusable the STL APIs 
really are!

Kevin Kofler

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Ville Voutilainen

On Thu, 22 Aug 2019 at 02:58, Konstantin Tokarev  wrote:

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

I can't do that. Python doesn't have static typing, value semantics,
and automatic scope cleanup.
And python's performance is horrible, so if I managed to not care
about performance when
programming in C++, I will start caring about it the instant I switch to Python.

(The point here is that C++ is not about sacrificing all else at the
altar of performance,
and never has been, and never will be.)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Ville Voutilainen

On Thu, 22 Aug 2019 at 15:17, 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.
>
> Transcoding source code from one encoding to another is actually pretty 
> trivial. The current status doesn’t advocate anything, meaning you’re not 
> even getting some slight push into this direction. Making it a compiler flag 
> defaulting to utf8 would be step forward.

You don't need to change the standard to get that, and changing the
standard doesn't give you that.

> Currently it defaults to the locale encoding of your machine, a completely 
> broken concept given that people cooperate on developing code over different 
> machines and across countries. Worse if you have includes from different 
> projects and both use different input encodings. There simply is no way to 
> make this work unless you restrict yours source code to pure ascii.

Even that's a subset. :P I have no particular heartburn about
restricting source code to pure ascii. I, like you, am from a locale
the characters of which many many
foreign readers find seriously weird, and I have never had any trouble
with the notion of restricting source code to pure ascii. I have
always wanted to maximize
the amount of people who can read my source code, and that means
emojis are out. :)

> In any case, we could advocate for utf8 being the input encoding when writing 
> Qt based code/projects or even make it the default. I wanted to do that for 
> Qt 5.0, but we couldn’t because MSVC didn’t support it at that time. It does 
> now however.

I must wonder.. are the benefits of that really that useful? I suppose
it's nice that you can just write utf-8 in your plain literals, but I
wonder why
a u"literal" is overly burdensome.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Matthew Woehlke

On 22/08/2019 17.00, Thiago Macieira wrote:
> For Qt 6, it is possible (and is still my goal[*]) to make creating a
> QString out of a QStringView and through it from a u"" literal happen
> in constant time, inlined, with no memory allocation.
How? Unless I miss something (which your example did not show),
QStringView doesn't know if the memory to which it points is rodata or
something else. If it's something else, you can't just stick it in a
QString and hope for the best, because it could change or cease to be
allocated at any time.

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

Re: [Development] HEADS-UP: QStringLiteral

On Thursday, 22 August 2019 14:01:50 PDT Matthew Woehlke wrote:
> On 22/08/2019 15.09, Danila Malyutin wrote:
> > Can't it be alleviated/improved by providing user-defined literal for
> > QString(Literal)? So that one would only write   a["b"_qs] = "c"_qs.
> 
> No; there is no (portable) way in C++17 (and I think still in C++20) for
> a UDL's return type to depend on the size (string length) of its input,
> which is required to implement QString literals. (I've tried...)

In Qt 5, the size is not sufficient, we need the actual content of the string. 
For Qt 6, that won't be needed, but we won't need an UDL 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

2019-08-22 Thread Matthew Woehlke

On 22/08/2019 15.09, Danila Malyutin wrote:
> Can't it be alleviated/improved by providing user-defined literal for
> QString(Literal)? So that one would only write   a["b"_qs] = "c"_qs.

No; there is no (portable) way in C++17 (and I think still in C++20) for
a UDL's return type to depend on the size (string length) of its input,
which is required to implement QString literals. (I've tried...)

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

Re: [Development] HEADS-UP: QStringLiteral

On Thursday, 22 August 2019 08:39:07 PDT Mutz, Marc via Development wrote:
> And QLatin1String and QStringLiteral are of Trolltech's making. Go to
> the internal history and go discuss with the original authors. From my
> pov, they solved and still solve particular needs. Those needs don't
> overlap, and they also don't overlap with simple "" or u"", so a
> programmer should be able to learn when to use which one. This isn't
> rocket science.

History:

QLatin1String is of Trolltech's making, it's from Qt 4.0 time. But it really 
came about because KDE during Qt3 days had a lot of

#define L1S(x)  QString::fromLatin1(x)

QLatin1String was required because in 3.x and 4.x QString's constructor used 
the *locale* codec, not a fixed codec. The locale codec is slow, since we 
factored out to iconv in 4.x. We don't know what it does, so we can't optimise 
it. It could even be one of the Asian not-exactly-ASCII compatible (where the 
backslash is ¥ or ₩).

That meant the following did work on all Unix we developed on (not Windows), 
but could fail in the field:
QString degree("\xc2\x80"); // U+0080

With 5.0, we switched to UTF-8 as the codec for the QString constructor, so  
you can write the above code and it will be what is expected.

But QLatin1String is retained because on 5.0, the UTF-8 codec was much slower 
than the Latin1 one. The SIMD-optimised  UTF-8 codec didn't come until later.

QStringLiteral is a 5.0 invention, so it's not Trolltech anymore. I'm the one 
who created that, so it's a hybrid of Nokia / Intel :-)

It was a very good solution given what we knew in 2011 and 2012 and the 
experience that was available with C++11 Unicode strings at the time. Now we 
know better and we know how to make it better. For Qt 6, it is possible (and 
is still my goal[*]) to make creating a QString out of a QStringView and 
through it from a u"" literal happen in constant time, inlined, with no memory 
allocation. A QStringView of such is a pair:
{ m_size: N, m_data: PTR }
a QString created from this QStringView would be:
{ m_size: N, m_data: PTR, d: nullptr }

[*] Unless we decide that QString always points to heap memory to avoid the 
plugin-unloading issue.

-- 
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-22 Thread Danila Malyutin

Can't it be alleviated/improved by providing user-defined literal for
QString(Literal)? So that one would only write   a["b"_qs] = "c"_qs.

чт, 22 авг. 2019 г. в 21:57, André Pönitz :

> On Thu, Aug 22, 2019 at 08:48:30PM +0200, André Pönitz wrote:
> > On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development
> wrote:
> > > I'm sorry if I sound blunt, but this is just nonsense. What you call
> > > optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> > > readable. As is just using "".
> >
> > I am not sorry to sound blunt here, but calling
> >
> >  a["b"] = "c"
> >
> > "equally readable" to
> >
> >  a[QStringLiteral("b")] = QStringLiteral("c")
> >
> > requires a kind of proficiency that's rare to find in real life.
>
> And to make it clear: I am not that proficient. To me the second version is
> 70% line noise and I in ordinary cases I happily pay cycles to have not to
> write or read that.
>
> Andre'
> ___
> 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-22 Thread André Pönitz

On Thu, Aug 22, 2019 at 08:48:30PM +0200, André Pönitz wrote:
> On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> > I'm sorry if I sound blunt, but this is just nonsense. What you call
> > optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> > readable. As is just using "".
> 
> I am not sorry to sound blunt here, but calling
> 
>  a["b"] = "c"
> 
> "equally readable" to
> 
>  a[QStringLiteral("b")] = QStringLiteral("c")
> 
> requires a kind of proficiency that's rare to find in real life.

And to make it clear: I am not that proficient. To me the second version is
70% line noise and I in ordinary cases I happily pay cycles to have not to
write or read that.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread André Pönitz

On Thu, Aug 22, 2019 at 05:39:07PM +0200, Mutz, Marc via Development wrote:
> I'm sorry if I sound blunt, but this is just nonsense. What you call
> optimisation, isn't. Using QStringLiteral or QLatin1String is equally
> readable. As is just using "".

I am not sorry to sound blunt here, but calling

 a["b"] = "c"

"equally readable" to

 a[QStringLiteral("b")] = QStringLiteral("c")

requires a kind of proficiency that's rare to find in real life.

I don't think it makes sense to move Qt into a direction that reduces
its potential audience to a handful people worldwide.


> Aye, it's more to _think_ and to _write_, but we don't care about those 
> metrics.

tr("Haeh?")

[And who is "we"?]

Andre'

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Tor Arne Vestbø


> On 22 Aug 2019, at 17:39, Mutz, Marc  wrote:
> 
> Aye, it's more to _think_ and to _write_, but we don't care about those 
> metrics.

Don’t say “we”, when you mean “I”. This hits the nail on the head. You may not 
care, but I for one do.

> The same goes for QList vs. QVector vs. std::vector. Anyone who claims that 
> one is any more or less readable than the other is ... to say it politely ... 
> mistaking brevity for clarity.

Yes, clearly these are equal in readability:

if (std::find(v.begin(), v.end(), x) != v.end())

if (v.contains(x))

臘‍♂️

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

Re: [Development] HEADS-UP: QStringLiteral


On 2019-08-22 15:42, Tor Arne Vestbø wrote:
On 22 Aug 2019, at 15:11, Mutz, Marc via Development 
 wrote:


We need to collectively understand that implementing a library is 
different from the library's API and from use of the API. Anyone who 
thinks otherwise is invited to have a look at qmetatype.h or 
qtypeinfo.h. All users see from this is Q_DECLARE_METATYPE, and we 
don't really care whether they use Q_DECLARE_TYPEINFO. But a Qt 
developer mustn't forget to add Q_DECLARE_TYPEINFO, because it's a BiC 
change to add it afterwards, and there are tons of Qt optimisations 
hinging on getting that correct. Qt developers are under very 
different constraints than Qt users, and we can't go on pretending 
that it's ok to develop Qt as if we were developing a throw-away Qt 
app and that profiling will show us where to optimise.


The notion that developing a generic library is “harder” than
application development is no excuse for not having good APIs for our
own internal use. Nor is it an excuse for micro optimising every code
path “just in case”. A lot of the “library” development in Qt are
features and convenience, where the availability and ease of use of
the feature is itself more important to our users than whether or not
it performs optimally in every single use-case. As long as the API is
not painting us into a corner the code can in many cases be optimised
incrementally when and if it turns out to be a problem.

Qt is a large project, with a wide range of areas. If the mental model
for developing Qt requires you to take into account every single
corner case or micro-optimisation possible you’ll end up with 10
perfect string classes and nothing that uses them because the feature
development will grind to a halt. This also goes for increasing
std-ization of Qt, where the use of the std-library ends up
obfuscating what the code is actually doing.


I'm sorry if I sound blunt, but this is just nonsense. What you call 
optimisation, isn't. Using QStringLiteral or QLatin1String is equally 
readable. As is just using "". Aye, it's more to _think_ and to _write_, 
but we don't care about those metrics. The same goes for QList vs. 
QVector vs. std::vector. Anyone who claims that one is any more or less 
readable than the other is ... to say it politely ... mistaking brevity 
for clarity.


So, given equally-readable alternatives, it behooves every programmer to 
choose the most efficient one. This is what is called "avoiding 
premature pessimisation", it's nothing new, it's not something I 
invented, it's coming up on 25 years of age, at least. And it is not 
optimisation, premature or otherwise. It was Scott Meyers that coined 
the term, though I'm sure good programmers have known this for decades, 
just not under that name.


And QLatin1String and QStringLiteral are of Trolltech's making. Go to 
the internal history and go discuss with the original authors. From my 
pov, they solved and still solve particular needs. Those needs don't 
overlap, and they also don't overlap with simple "" or u"", so a 
programmer should be able to learn when to use which one. This isn't 
rocket science.


And, finally, if I hear, once more, implied or explicitly, about how 
wonderfully readable Qt sources are, or "were", implying "before Marc 
came and ruined everything", I _will_ print QBezier::split() in the 5.13 
form and throw it from Frankfurt all the way to Oslo.


Seriously.

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

Re: [Development] HEADS-UP: QStringLiteral

On Thursday, 22 August 2019 05:31:44 PDT Edward Welbourne wrote:
> That's the UTF8 path Thiago is talking about.
> There is no short-cut, although I do wonder why there isn't a "search
> for the first byte whose top bit is set", which might equip us with one.

There is. It's that code you didn't understand: the simdDecodeAscii() function 
is called from the UTF-8 decoder and fails only if the input isn't ASCII.

for ( ; end - src >= 16; src += 16, dst += 16) {
__m128i data = _mm_loadu_si128((const __m128i*)src);
[load 16 characters]

#ifdef __AVX2__
const int BitSpacing = 2;
// load and zero extend to an YMM register
const __m256i extended = _mm256_cvtepu8_epi16(data);
[this is the Latin1 to UTF16 expansion, but may be wrong]

uint n = _mm256_movemask_epi8(extended);
[this extracts the high bit from each byte]
if (!n) {
// store
_mm256_storeu_si256((__m256i*)dst, extended);
continue;
[if the input was US-ASCII, repeat]
}

[here, we handle the case of the input containing non-ASCII: store the input 
that was US-ASCII, the find the first US-ASCII scanning backwards from the 
end]

-- 
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 Thursday, 22 August 2019 05:49:19 PDT Edward Welbourne wrote:
> The complication is that, unless you have a *very* liberal meaning of "a
> few", that's not the choice you're faced with.  Converting from UTF-8
> sure looks a lot more expensive (from what I've seen of the code) than
> converting from ISO-Latin-1.

It is, but our code is smart. It tries to first do a full SIMD decode of the 
content as if it were US-ASCII and then checks if there's anything non-ASCII 
there. So for UTF-8 input that is *also* US-ASCII, the performance of our 
fromUtf8 should be within 5% of the fromLatin1 performance.

This is implemented for both x86 and AArch64. (Performance numbers for AArch64 
may be different)

> OTOH, if we could bear the heavy burden of using u"..." for strings
> where we care about speed more than size, u8"..." for those where the
> content isn't pure ASCII but we care about size more than speed, and
> accept only ever using plain old C "..."  when its contents are pure
> ASCII, I think we can realistically hope to achieve some significant
> simplifications.

We need to make an assessment of what the C++20 changes mean for u8"" first, 
since it changes from char[] literal to char8_t[] literal. Adding the 
overloads to QString is easy, but we may have places that take a const char*, 
put it in a variable, then pass to a QString. Those will need updating.

-- 
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-22 Thread Matthew Woehlke

On 22/08/2019 09.41, Martin Smith wrote:
> If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it
> important for users?
...because users, especially application authors, typically have far
greater latitude to make BiC and even SiC changes compared to library
authors. Also, because they don't have the same obligation to make
*everything* fast.

If a user does not use Q_DECLARE_TYPEINFO initially, maybe they just
don't need it, and even if they do, it is probably not an issue to add
it later. If Qt neglects to use it for some type, it can't be fixed
until a major version.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Konstantin Tokarev

22.08.2019, 17:14, "Edward Welbourne" :
> Konstantin Tokarev (22 August 2019 15:48) wrote:
>>  At least we need a wiki page with optimization guidelines
>
> Would a page in our documentation suffice ?
> https://codereview.qt-project.org/c/qt/qtdoc/+/268079
>

Sure, though I've meant not only use of strings but other kinds of 
optimizations which
Marc is adding to Qt code base. Something like "Efficient Qt" but updated to the
current state of the art.

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Edward Welbourne

Konstantin Tokarev (22 August 2019 15:48) wrote:
> At least we need a wiki page with optimization guidelines

Would a page in our documentation suffice ?
https://codereview.qt-project.org/c/qt/qtdoc/+/268079

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Konstantin Tokarev



22.08.2019, 16:44, "Martin Smith" :
> But Marc, your last paragraph calls for separating the API and implementation 
> discussions, but the paragraph just before it argues that the API to work 
> around our slowness is vital.
>
> If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it important 
> for users?
>
> Should we have a pre-Qt 6 optimization period, where you first write up an 
> exhaustive list of all the implementation optimizations that should be used 
> in all Qt library code, and then we take the time to ensure that every class 
> uses them?
>
> I'm still not seeing why these same optimizations shouldn't be important to 
> describe in the Qt documentation for users. Users look at the Qt source code, 
> so when they see Q_DECLARE_TYPEINFO, they should be able to find out what it 
> does.

At least we need a wiki page with optimization guidelines

-- 
Regards,
Konstantin

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Tor Arne Vestbø

> On 22 Aug 2019, at 15:11, Mutz, Marc via Development 
>  wrote:
> 
> We need to collectively understand that implementing a library is different 
> from the library's API and from use of the API. Anyone who thinks otherwise 
> is invited to have a look at qmetatype.h or qtypeinfo.h. All users see from 
> this is Q_DECLARE_METATYPE, and we don't really care whether they use 
> Q_DECLARE_TYPEINFO. But a Qt developer mustn't forget to add 
> Q_DECLARE_TYPEINFO, because it's a BiC change to add it afterwards, and there 
> are tons of Qt optimisations hinging on getting that correct. Qt developers 
> are under very different constraints than Qt users, and we can't go on 
> pretending that it's ok to develop Qt as if we were developing a throw-away 
> Qt app and that profiling will show us where to optimise.

The notion that developing a generic library is “harder” than application 
development is no excuse for not having good APIs for our own internal use. Nor 
is it an excuse for micro optimising every code path “just in case”. A lot of 
the “library” development in Qt are features and convenience, where the 
availability and ease of use of the feature is itself more important to our 
users than whether or not it performs optimally in every single use-case. As 
long as the API is not painting us into a corner the code can in many cases be 
optimised incrementally when and if it turns out to be a problem.

Qt is a large project, with a wide range of areas. If the mental model for 
developing Qt requires you to take into account every single corner case or 
micro-optimisation possible you’ll end up with 10 perfect string classes and 
nothing that uses them because the feature development will grind to a halt. 
This also goes for increasing std-ization of Qt, where the use of the 
std-library ends up obfuscating what the code is actually doing. 

Tor Arne

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Martin Smith

But Marc, your last paragraph calls for separating the API and implementation 
discussions, but the paragraph just before it argues that the API to work 
around our slowness is vital.

If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it important for 
users?

Should we have a pre-Qt 6 optimization period, where you first write up an 
exhaustive list of all the implementation optimizations that should be used in 
all Qt library code, and then we take the time to ensure that every class uses 
them?

I'm still not seeing why these same optimizations shouldn't be important to 
describe in the Qt  documentation for users. Users look at the Qt source code, 
so when they see Q_DECLARE_TYPEINFO, they should be able to find out what it 
does.

From: Development  on behalf of Mutz, Marc 
via Development 
Sent: Thursday, August 22, 2019 3:11 PM
To: Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral

On 2019-08-22 14:48, Martin Smith wrote:
> Now that we use clang in Creator and QDoc, suppose we write a QString
> source code analysis tool using clang. The tool would parse sources
> looking for uses of QString and then analyzing the code patterns where
> QString is used to find possible optimizations using the other Qt
> string classes.
>
> The output is a report suggesting the possible optimizations. Then we
> can tell customers to write code with QString first, because that's
> easy. When it works, run this tool and see where you can improve
> performance and which string classes to use.

Yes, that tool is called Clazy :)

Please note that I, the thread starter, never claimed that users should
need to know all about QL1S, QSL, QSV, ... but Qt developers should. I'm
totally fine with users writing

   QHash map;
   map["one"] = "uno";
   map["two"] = "due";
   ~~~

At the same time, I find that this is utterly unacceptable in library
code, ie. Qt implementation.

We need to collectively understand that implementing a library is
different from the library's API and from use of the API. Anyone who
thinks otherwise is invited to have a look at qmetatype.h or
qtypeinfo.h. All users see from this is Q_DECLARE_METATYPE, and we don't
really care whether they use Q_DECLARE_TYPEINFO. But a Qt developer
mustn't forget to add Q_DECLARE_TYPEINFO, because it's a BiC change to
add it afterwards, and there are tons of Qt optimisations hinging on
getting that correct. Qt developers are under very different constraints
than Qt users, and we can't go on pretending that it's ok to develop Qt
as if we were developing a throw-away Qt app and that profiling will
show us where to optimise.

We can't profile all Qt applications out there, so the chance is high
that _some_ Qt implementation will be a bottleneck for _someone_. And if
that someone can't work around our slowness, they will use a different
tool, or will have to write their own. If they succeed in doing so
without a huge invest of resources, they will ask us: "if it was so easy
to make this 50% faster, why did I have to do this, why isn't this in Qt
already"? No-one can seriously want that.

So, I'm really disappointed, and I'm not intending to single you out
here, Martin, but it seems to me that well-meaning emails regarding Qt
_implementation_ are hijacked and transformed into discussions about Qt
_API_. We should have these discussions, both of them, but we mustn't
conflate these two very different aspects.

Thanks,
Marc
___
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 2019-08-22 14:59, Kevin Kofler wrote:

Mutz, Marc via Development wrote:

For me, the problem is QUtf8XXX::size() - what should that return?!


IMHO, obviously the number of bytes. You can have additional O(N)
numCodePoints() and (if needed) utf16Size() (which takes needed 
surrogate
pairs into account) methods, but the inherent size is the number of 
bytes.


IOW: what's the meaning of an index into a UTF-8 string? That extends 
to

mid(), left(), right(), split(), ...


IMHO, a byte index, and if that chops the codepoint, so be it, same as 
for
the surrogate pairs in the UTF-16 QString. Anything else is just not 
doable

with reasonable efficiency.


That I would see the day I agree with you... :)

But that leaves the task of identifying which of pre-existing size() 
calls mean "number of characters" and which ones do "number of code 
points" to the users. And it makes rightJustified() and leftJustified() 
all but pointless. So this isn't without problems, but I agree the 
alternative is worse.


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

Re: [Development] HEADS-UP: QStringLiteral


On 2019-08-22 14:48, Martin Smith wrote:

Now that we use clang in Creator and QDoc, suppose we write a QString
source code analysis tool using clang. The tool would parse sources
looking for uses of QString and then analyzing the code patterns where
QString is used to find possible optimizations using the other Qt
string classes.

The output is a report suggesting the possible optimizations. Then we
can tell customers to write code with QString first, because that's
easy. When it works, run this tool and see where you can improve
performance and which string classes to use.


Yes, that tool is called Clazy :)

Please note that I, the thread starter, never claimed that users should 
need to know all about QL1S, QSL, QSV, ... but Qt developers should. I'm 
totally fine with users writing



  QHash map;
  map["one"] = "uno";
  map["two"] = "due";
  ~~~

At the same time, I find that this is utterly unacceptable in library 
code, ie. Qt implementation.


We need to collectively understand that implementing a library is 
different from the library's API and from use of the API. Anyone who 
thinks otherwise is invited to have a look at qmetatype.h or 
qtypeinfo.h. All users see from this is Q_DECLARE_METATYPE, and we don't 
really care whether they use Q_DECLARE_TYPEINFO. But a Qt developer 
mustn't forget to add Q_DECLARE_TYPEINFO, because it's a BiC change to 
add it afterwards, and there are tons of Qt optimisations hinging on 
getting that correct. Qt developers are under very different constraints 
than Qt users, and we can't go on pretending that it's ok to develop Qt 
as if we were developing a throw-away Qt app and that profiling will 
show us where to optimise.


We can't profile all Qt applications out there, so the chance is high 
that _some_ Qt implementation will be a bottleneck for _someone_. And if 
that someone can't work around our slowness, they will use a different 
tool, or will have to write their own. If they succeed in doing so 
without a huge invest of resources, they will ask us: "if it was so easy 
to make this 50% faster, why did I have to do this, why isn't this in Qt 
already"? No-one can seriously want that.


So, I'm really disappointed, and I'm not intending to single you out 
here, Martin, but it seems to me that well-meaning emails regarding Qt 
_implementation_ are hijacked and transformed into discussions about Qt 
_API_. We should have these discussions, both of them, but we mustn't 
conflate these two very different aspects.


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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Kevin Kofler

Mutz, Marc via Development wrote:
> For me, the problem is QUtf8XXX::size() - what should that return?!

IMHO, obviously the number of bytes. You can have additional O(N) 
numCodePoints() and (if needed) utf16Size() (which takes needed surrogate 
pairs into account) methods, but the inherent size is the number of bytes.

> IOW: what's the meaning of an index into a UTF-8 string? That extends to
> mid(), left(), right(), split(), ...

IMHO, a byte index, and if that chops the codepoint, so be it, same as for 
the surrogate pairs in the UTF-16 QString. Anything else is just not doable 
with reasonable efficiency.

Kevin Kofler

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

Re: [Development] HEADS-UP: QStringLiteral

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


Il 22/08/19 14:48, Martin Smith ha scritto:

The output is a report suggesting the possible optimizations. Then we can tell 
customers to write code with QString first, because that's easy. When it works, 
run this tool and see where you can improve performance and which string 
classes to use.

We could do the same for QList.


The tool exists and is called clazy:


https://github.com/KDE/clazy


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

2019-08-22 Thread Edward Welbourne

Lars Knoll (22 August 2019 13:55)
> The problem with our multitude of string classes is not only that
> we’re overcomplicating our API, but also that we’re adding
> implementation complexity for ourselves that we will need to maintain
> over the years to come. I would very much wish that we could find ways
> to reduce that complexity with Qt 6.

+1.

> And I’d be willing to pay with a few additional CPU cycles here and
> there to achieve that.

The complication is that, unless you have a *very* liberal meaning of "a
few", that's not the choice you're faced with.  Converting from UTF-8
sure looks a lot more expensive (from what I've seen of the code) than
converting from ISO-Latin-1.

OTOH, if we could bear the heavy burden of using u"..." for strings
where we care about speed more than size, u8"..." for those where the
content isn't pure ASCII but we care about size more than speed, and
accept only ever using plain old C "..."  when its contents are pure
ASCII, I think we can realistically hope to achieve some significant
simplifications.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Martin Smith

Now that we use clang in Creator and QDoc, suppose we write a QString source 
code analysis tool using clang. The tool would parse sources looking for uses 
of QString and then analyzing the code patterns where QString is used to find 
possible optimizations using the other Qt string classes.

The output is a report suggesting the possible optimizations. Then we can tell 
customers to write code with QString first, because that's easy. When it works, 
run this tool and see where you can improve performance and which string 
classes to use.

We could do the same for QList.

martin

From: Development  on behalf of Edward 
Welbourne 
Sent: Thursday, August 22, 2019 2:31 PM
To: Lars Knoll
Cc: Thiago Macieira; Qt development mailing list
Subject: Re: [Development] HEADS-UP: QStringLiteral

On 21 Aug 2019, at 17:55, Thiago Macieira  wrote:
>> 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.

Lars Knoll (22 August 2019 13:42) replied:
> We could also turn this around: Are we over-optimising here? Do we
> have the right balance between ease of use and performance? Converting
> utf8 is a bit more costly than latin1, but would that ever matter in
> real world use cases?

I guess that's a matter of how much of a performance penalty you're
willing to pay.

If you look at qtbase/src/corelib/codecs/qutfcodec.cpp you'll see it's
all very non-trivial - and makes heavy use of functions that are heavily
optimised to exploit particular instruction sets to squeeze all the
boosts they can into the performance.  It's highly complex and I won't
pretend to understand it.  That's the UTF8 path Thiago is talking about.
There is no short-cut, although I do wonder why there isn't a "search
for the first byte whose top bit is set", which might equip us with one.

The QLatin1String path is essentially qt_from_latin1() in qstring.cpp;
50 lines of code, vs several hundred; it does have some fancy
optimisations to exploit special CPU instructions; but one of its #if
paths really is just

while (size--)
*dst++ = (uchar)*str++;

i.e., as Thiago said, essentially (except for *dst being bigger than
*str) memcpy().  The other code paths are ways to optimise that.

The latter is obviously way cheaper than the former.  Is that a price
you're willing to pay, throughout all our library code, for ease of
writing library code ?

Eddy.
___
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 2019-08-22 13:42, Lars Knoll wrote:
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.


We could also turn this around: Are we over-optimising here? Do we
have the right balance between ease of use and performance? Converting
utf8 is a bit more costly than latin1, but would that ever matter in
real world use cases?


Once we have proper support for u8 (in Qt, and C++ (char8_t)), we can 
certainly think about phasing out QLatin1String. Personally, I don't 
think the decoding performance between L1 and UTF-8 is the key here.


UTF-8 even has the nice property that it's closed under all text 
transformations in all locales, unlike L1 (toupper('ß') == ẞ ∉ L1, 
tolower('I') @ tr_TR = ı ∉ L1, ...). QUtfXXX would also greatly reduce 
the number of overloads of core string functions we need to provide (the 
same way as QStringView does already, if you consider 
QT_STRINGVIEW_LEVEL >= 2).


For me, the problem is QUtf8XXX::size() - what should that return?! IOW: 
what's the meaning of an index into a UTF-8 string? That extends to 
mid(), left(), right(), split(), ... In all current Qt string classes, 
size() returns the number of characters (ignoring surrogate pairs in 
QString, which we probably can live with because there are different 
ways to spell a ä in Unicode, too (ä, a + ¨), such that any serious text 
processing is anyway far removed from the simplistic 1 code point = 1 
glyph pov, so surrogate pairs aren't much of an issue anymore). Whatever 
we do here, it will be downhill from where we are. Either size() is O(N) 
or a string (view) is no longer the size of a pointer (or two). That's 
2x (50%+0) O(1) memory per string (view), and such stuff adds up over 
1000s of strings...


So, maybe, at some point in the future, we can axe QLatin1String. But we 
need to seriously up UTF-8 support in Qt before that. QString is kind of 
in the way here, as UTF-16 has the bad side effect of endian dependence. 
If, say, .qm files were stored in UTF-8, tr() could return a QUtf8View. 
That's not possible with QString, unless apps come with two .qm files, 
one LE and BE.


One way to get out of this history pit was mentioned here and there on 
this ML before: we could have a QAnyString(View) (all names subject to 
bikeshedding), a string (view) that type-erases the encoding (like a 
std::variant), 
which would be the type used in higher-level APIs 
(QLineEdit::setText(QAnyStringView)). I think std::filesystem::path got 
that quite right: you can feed it UTF-8 or UTF-16, and it will 
transparently convert to and from native API's encoding as needed.


But such a type has to be an _addition_ to, not a replacement of, 
encoding-dependent string types (proof: how do you process a 
QAnyString(View) if you're given one? Probably, keeping the std::variant 
simile, with a visitation mechanism, and the visitor is overloaded on 
the type. Sure, you can use (char8_t*, qsizetype) and (char16_t, 
qizetype) for that, but then we're back to a place we thought we'd never 
go back to after we got views: C-like string manipulation APIs.


Flame away...

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Edward Welbourne

On 21 Aug 2019, at 17:55, Thiago Macieira  wrote:
>> 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.

Lars Knoll (22 August 2019 13:42) replied:
> We could also turn this around: Are we over-optimising here? Do we
> have the right balance between ease of use and performance? Converting
> utf8 is a bit more costly than latin1, but would that ever matter in
> real world use cases?

I guess that's a matter of how much of a performance penalty you're
willing to pay.

If you look at qtbase/src/corelib/codecs/qutfcodec.cpp you'll see it's
all very non-trivial - and makes heavy use of functions that are heavily
optimised to exploit particular instruction sets to squeeze all the
boosts they can into the performance.  It's highly complex and I won't
pretend to understand it.  That's the UTF8 path Thiago is talking about.
There is no short-cut, although I do wonder why there isn't a "search
for the first byte whose top bit is set", which might equip us with one.

The QLatin1String path is essentially qt_from_latin1() in qstring.cpp;
50 lines of code, vs several hundred; it does have some fancy
optimisations to exploit special CPU instructions; but one of its #if
paths really is just

while (size--)
*dst++ = (uchar)*str++;

i.e., as Thiago said, essentially (except for *dst being bigger than
*str) memcpy().  The other code paths are ways to optimise that.

The latter is obviously way cheaper than the former.  Is that a price
you're willing to pay, throughout all our library code, for ease of
writing library code ?

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Tor Arne Vestbø



> On 22 Aug 2019, at 13:55, Lars Knoll  wrote:
> 
> The problem with our multitude of string classes is not only that we’re 
> overcomplicating our API, but also that we’re adding implementation 
> complexity for ourselves that we will need to maintain over the years to 
> come. I would very much wish that we could find ways to reduce that 
> complexity with Qt 6. And I’d be willing to pay with a few additional CPU 
> cycles here and there to achieve that.

Hear hear!!! 

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Lars Knoll

> On 21 Aug 2019, at 13:13, Ville Voutilainen  
> wrote:
> 
> 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.

Transcoding source code from one encoding to another is actually pretty 
trivial. The current status doesn’t advocate anything, meaning you’re not even 
getting some slight push into this direction. Making it a compiler flag 
defaulting to utf8 would be step forward. 

Currently it defaults to the locale encoding of your machine, a completely 
broken concept given that people cooperate on developing code over different 
machines and across countries. Worse if you have includes from different 
projects and both use different input encodings. There simply is no way to make 
this work unless you restrict yours source code to pure ascii.

In any case, we could advocate for utf8 being the input encoding when writing 
Qt based code/projects or even make it the default. I wanted to do that for Qt 
5.0, but we couldn’t because MSVC didn’t support it at that time. It does now 
however.

Cheers,
Lars

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Lars Knoll

> On 22 Aug 2019, at 01:56, Konstantin Tokarev  wrote:
> 
> 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.

A good framework is there to help our users create the applications they want 
to create. It’s a fact that most of the code our users write is not performance 
critical. Development time and the time it takes to debug and finish a product 
until it can be launched is much more crucial for most of our users than a 
couple of percent more performance.

This is something to keep in mind. Ideally, we can combine both goals and have 
easy to use APIs that hide most of the complexity from the user, while at the 
same time delivering good performance. 

But in some cases it’s ok, to add a few cycles to make things easier for our 
users (and before someone cries out: I am not taking about anything that 
changes complexity of algorithms).

>> 
>> 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.

That’s a wrong argument. There are many reasons people want to or need to use 
C++. The UIs of apps are to the largest part not performance sensitive. Most of 
the time they are idling and waiting for user input. And yes, the 1-5% of the 
code that is performance sensitive is something you can and should be able to 
hand-optimise.

The problem with our multitude of string classes is not only that we’re 
overcomplicating our API, but also that we’re adding implementation complexity 
for ourselves that we will need to maintain over the years to come. I would 
very much wish that we could find ways to reduce that complexity with Qt 6. And 
I’d be willing to pay with a few additional CPU cycles here and there to 
achieve that.

Cheers,
Lars

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Lars Knoll

> On 21 Aug 2019, at 17:55, Thiago Macieira  wrote:
> 
> 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.

We could also turn this around: Are we over-optimising here? Do we have the 
right balance between ease of use and performance? Converting utf8 is a bit 
more costly than latin1, but would that ever matter in real world use cases? 

Cheers,
Lars


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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Arnaud Clere

-Original Message-
> From: Konstantin Tokarev  
> > 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.

Please stop using such dismissive arguments.
I have been using C++ for decades for a lot of different applications from 
servers to GUIs.
For GUIs 99% of the code did not need to reason about performance.
For servers, actual performance depended on hardly more than 5-10% of the 
code...

Clarity and readability was needed in almost all the source!

I love Qt because it allows me to write readable C++ code most of the time.
As André, I'm Ok with not using Qt in the very few places where Qt sacrificed 
performance for simplicity and performance is actually needed by the 
application.

Requiring people to use one language for performance and another one for 
readability is unreasonable for obvious technical and organizational reasons.

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Olivier Goffart


On 21.08.19 17:55, Thiago Macieira wrote:

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.


I'd claim the cost of the conversion is negligible compared to the cost of the 
extra allocation.  (so in the case above, "..." or u"..." or QL1S("...") makes 
no real speed difference, QStringLiteral("...") does)

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

Re: [Development] HEADS-UP: QStringLiteral



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] 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] 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] 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] 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] 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

2019-08-21 Thread Edward Welbourne

>> 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] 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

2019-08-21 Thread Edward Welbourne

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

2019-08-21 Thread Edward Welbourne

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

2019-08-21 Thread Jean-Michaël Celerier

> 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 ?).

On Tue, Aug 20, 2019 at 11:41 PM Thiago Macieira 
wrote:

> On Tuesday, 20 August 2019 14:25:27 PDT Philippe wrote:
> > > There's no mutex.
> >
> > On Visual Studio 2017 15.8.8,
>
> That's a broken compiler, a regression from 2015 and fixed on 2019. Try
> *any*
> other compiler and you'll see there's no mutex.
>
> Same bug that makes static with VS 2017 crash on start.
>
> --
> 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] HEADS-UP: QStringLiteral

On Tuesday, 20 August 2019 14:25:27 PDT Philippe wrote:
> > There's no mutex.
> 
> On Visual Studio 2017 15.8.8, 

That's a broken compiler, a regression from 2015 and fixed on 2019. Try *any* 
other compiler and you'll see there's no mutex.

Same bug that makes static with VS 2017 crash on start.

-- 
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-20 Thread Philippe

> There's no mutex.

On Visual Studio 2017 15.8.8, there is a mutex on the 1st call
(checked today when step tracing the assembly code).

Again, for block scope, that is:

void foo()
{
QString s = QStringLiteral("abc");
...
}

Philippe

On Tue, 20 Aug 2019 14:11:59 -0700
Thiago Macieira  wrote:

> On Tuesday, 20 August 2019 03:41:45 PDT Philippe wrote:
> > another Drawback : it causes a global mutex to be executed on first use
> > inside a block scope (c++11 static variable thread safety).
> 
> There's no mutex.
> 
> -- 
> 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] 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?

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.

-- 
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 Tuesday, 20 August 2019 03:41:45 PDT Philippe wrote:
> another Drawback : it causes a global mutex to be executed on first use
> inside a block scope (c++11 static variable thread safety).

There's no mutex.

-- 
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