On Fri, 23 Aug 2019 at 09:37, Mutz, Marc via Development
wrote:
> But up to and incl. C++17, the only way to make "foo"_qs work is by
> operator ""_qs(const char *, std::size_t), which is not a template, so
> all it can do is call QString::fromUtf8(), which would be a step back
> from what we have
On Fri, 23 Aug 2019 at 09:02, Lars Knoll wrote:
>
> > On 22 Aug 2019, at 23:43, 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
On 2019-08-22 21: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.
Yes.
++ways_to_construct;
:)
Fun aside, in C++20, this may actually alleviate some of the problems of
QStr
On 2019-08-22 23:43, Ville Voutilainen wrote:
I have
always wanted to maximize
the amount of people who can read my source code, and that means
emojis are out. :)
I don't believe European languages as written by you and me are the
benchmark here. Asian locales (incl. Russian/Cyrillic) are. It
> On 22 Aug 2019, at 23:43, 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. I
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 me
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
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
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
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
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 no
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++
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 s
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
> overla
On Thursday, 22 August 2019 12:05:39 PDT Danila Malyutin wrote:
> Isn't it already the case: https://doc.qt.io/qt-5/supported-platforms.html
> ?
Looks like it.
I'll dust-off the Q_THREAD_LOCAL patch and send it off through the CI. If any
platform can't compile it, we'll just remove the platfor
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
Isn't it already the case: https://doc.qt.io/qt-5/supported-platforms.html
?
чт, 22 авг. 2019 г. в 18:10, Thiago Macieira :
> On Wednesday, 21 August 2019 17:17:17 PDT Kevin Kofler wrote:
> > > So let me instead change my request:
> > > Can we require GCC 8 for MinGW for Qt 5.15?
> >
> > This i
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
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 callin
> 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. A
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 qmetaty
On Wednesday, 21 August 2019 23:37:35 PDT Henry Skoglund wrote:
> Aha, sorry for my ignorance! Yes, Thiago wrote about the -static-runtime
> option yesterday, I have to try it out (perhaps also wait for that
> update 16.0 to MSVC2017, when it supposedly has less static-flavored bugs)
The 16.0 upda
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 un
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 f
On Wednesday, 21 August 2019 17:17:17 PDT Kevin Kofler wrote:
> > So let me instead change my request:
> > Can we require GCC 8 for MinGW for Qt 5.15?
>
> This is a much more reasonable request than the original one.
>
> For what it's worth, the oldest still supported Fedora release (Fedora 29)
>
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
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
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
Dev
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 i
> 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 se
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
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
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
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 i
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.
W
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 f
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
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 perf
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?
În ziua de joi, 22 august 2019, la 15:17:33 EEST, Tor Arne Vestbø a scris:
> > 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 our
> 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
> 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
> 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,
> 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, i
-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 na
45 matches
Mail list logo
