Re: [Development] HEADS-UP: QStringLiteral

2019-08-28 Thread Paul Tvete
On Wednesday, 28 August 2019 07:21:06 CEST Thiago Macieira wrote: > Anyway, doing a memory wipe. Aside from ISO-8859-1, I don't want to think of > any of the others for another 15 years. I apologize deeply, but I cannot resist the temptation to share the diagram of Japanese character encodings fr

Re: [Development] HEADS-UP: QStringLiteral

2019-08-27 Thread Thiago Macieira
On Tuesday, 27 August 2019 16:57:55 PDT Kevin Kofler wrote: > If you do not explicitly add ".UTF-8", glibc always gives you the obsolete > legacy locale with the locale-specific pre-Unicode character set. This is > intentional for backwards compatibility. So you should never use a locale > without

Re: [Development] HEADS-UP: QStringLiteral

2019-08-27 Thread Kevin Kofler
Edward Welbourne wrote: > clang, gcc read input the same with LC_ALL unset and set variously to C, > POSIX, en_US, pt_BR, el_GR. I note that none of these explicitly > selects an encoding, so the doc above is indeed consistent with gcc > guessing UTF-8 based on the value of LC_ALL. Even if the on

Re: [Development] HEADS-UP: QStringLiteral

2019-08-27 Thread Edward Welbourne
Thiago had said: >>> GCC and Clang default to UTF-8 *unless* you pass -finput-charset to >>> something different, independent of what your locale is. On Monday, 26 August 2019 09:20:49 PDT Lars Knoll wrote: >> That wasn’t how I understood it. Here’s the corresponding man page >> entry from gcc: >>

Re: [Development] HEADS-UP: QStringLiteral

2019-08-26 Thread Thiago Macieira
On Monday, 26 August 2019 09:20:49 PDT Lars Knoll wrote: > > GCC and Clang default to UTF-8 *unless* you pass -finput-charset to > > something different, independent of what your locale is. > > That wasn’t how I understood it. Here’s the corresponding man page entry > from gcc: > > -finput-charse

Re: [Development] HEADS-UP: QStringLiteral

2019-08-26 Thread Lars Knoll
> On 26 Aug 2019, at 07:53, Thiago Macieira wrote: > > On Monday, 26 August 2019 05:02:28 PDT Lars Knoll wrote: >>> And we've done that and all of Qt's modules build like that. >> >> Really? It’s probably what happens in practice in most cases on Linux and >> macOS, as their locale is utf-8, but

Re: [Development] HEADS-UP: QStringLiteral

2019-08-26 Thread Thiago Macieira
On Monday, 26 August 2019 05:02:28 PDT Lars Knoll wrote: > > And we've done that and all of Qt's modules build like that. > > Really? It’s probably what happens in practice in most cases on Linux and > macOS, as their locale is utf-8, but we do not force the input encoding to > anything as far as

Re: [Development] HEADS-UP: QStringLiteral

2019-08-26 Thread Lars Knoll
> On 23 Aug 2019, at 17:04, Thiago Macieira wrote: > > On Thursday, 22 August 2019 23:44:02 PDT Ville Voutilainen wrote: >>> This doesn’t solve the problem that you’re having when you want to use >>> anything outside the ascii range inside “literal”, as the encoding of the >>> source code on disk

Re: [Development] HEADS-UP: QStringLiteral

2019-08-23 Thread Thiago Macieira
On Thursday, 22 August 2019 23:44:02 PDT Ville Voutilainen wrote: > > This doesn’t solve the problem that you’re having when you want to use > > anything outside the ascii range inside “literal”, as the encoding of the > > source code on disk is not defined. u”…” or u8”…” defines the output > > enc

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Ville Voutilainen
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Ville Voutilainen
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Lars Knoll
> 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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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

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

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

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

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 no

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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++

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 s

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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

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

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

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 callin

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Thiago Macieira
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

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

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

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 Dev

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 i

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 se

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Martin Smith
t 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 > loo

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

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 i

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

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 f

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Martin Smith
artin 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: >

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Mutz, Marc via Development
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

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?

Re: [Development] HEADS-UP: QStringLiteral

2019-08-22 Thread Bogdan Vatra via Development
Î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

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

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

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,

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

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 na

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 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 explicitne

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Konstantin Tokarev
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 >>  appl

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

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

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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, t

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 sen

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 d

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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 th

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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 stri

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 sh

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Konstantin Tokarev
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. >

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 automatic

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread 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. -- Thiago Macieira - thiago.macieira (AT) intel.c

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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. Bu

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 mis

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Konstantin Tokarev
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 Wedn

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread 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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Konstantin Tokarev
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Konstantin Tokarev
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread 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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread 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. Opt

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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.

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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 con

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Thiago Macieira
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 sprin

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 t

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:

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

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

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

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 b

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 o

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

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

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

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Jaroslaw Kobus
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 Developm

Re: [Development] HEADS-UP: QStringLiteral

2019-08-21 Thread Tor Arne Vestbø
> 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 complete

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 wer

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 handli

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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-20 Thread Thiago Macieira
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.

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 Maci

Re: [Development] HEADS-UP: QStringLiteral

2019-08-20 Thread Thiago Macieira
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

Re: [Development] HEADS-UP: QStringLiteral

2019-08-20 Thread Thiago Macieira
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 Syste

  1   2   >