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
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
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
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:
>>
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
> 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
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
> 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
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
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
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
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 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 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
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
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
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:
>
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
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
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
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
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
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
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
Î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
> 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
> 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
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
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
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
> 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
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.
>
> 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
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
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
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
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
> 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
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
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
> 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
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
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
> 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
> 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
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.
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
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
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
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:
>> 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
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
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
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
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
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…)
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
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
> 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
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
> 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
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
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
> 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
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.
> 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
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
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 - 100 of 104 matches
Mail list logo